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1. EXECUTIVE 

Tne HEP Executive resides on a Digital Equipment Corporation 
PDP-11 computer. It provides operating system services associated 
with physical I/O, job preparation* maintenance and debugging. In 
general, any operating system function whose execution time is not 
critical is provided by the Executive. 

Executive services are provided by Executive tasks, which are 
described in mere detail later in this section. These tasks are 
coordinated by a mini-operating system in the PDP-11. Tnis mini-OS, 
called the ROOT, manages memory for the Executive tasks, protects 
tnem from each other, and provides certain services to the Executive 
tasks . 

1.1 Root 

The Root is the only Executive module written directly in 
assembly language. The Root is loaded into low PDP-11 memory by 
the boot- strap process. Other Executive tasks exist as 
independent disk files, and are loaded by tne Root as part of the 
system initialization. Thus, Executive tasks are separately 
compiled, and may be changed without rebuilding the entire 
operating system. Initialization of the disk for system boot is 
handled by a specialized task - the Disk Builder (DB) and is 
discussed later under that heading. 

1.1.1 Basic Services 



Once all Executive tasks are loaded, the Root provides 
basic operating system services to the tasks. Tnese services 
are described on the next page. 
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1.1.1.1. Task Management 

Each Executive task is allocated a certain amount 
of memory for execution. The address space of each task 
is allocated by the Root as follows: 

0-8K Code-Read Access 

8-16K Code-Read Access 

-16-24K Code-Read Access 

24-32K Code-Read Access 

32-40K Data-Read/Write Access 

40-48K Message-Read/Write Access 
(only 128 bytes used) 

48-56K Message-Read/Wr i te Access 
(only 128 bytes used) 

56-64K I/O Page-Read/Write Access 

Tne physical memory associated with this 64K byte 
address space is fixed by the Root at IPL time, and 
remains allocated forever. Task context switching is 
nandled by the Root, and involves the manipulation of 
trie PDP-11 memory management registers to protect and 
isolate tasks from each other. 

Executive tasks are dispatcned strictly in 
priority order. The priorities are determined by the 
order of tasks at Disk Build time. Root task management 
routines always dispatcn the highest priority ready 
task. While there is considerable latitude in the 
dispatching order of tasks, inappropriate dispatching 
priorities can result in system failure. 

1.1.1.2 Message Routing 

Terminal and inter-task communications are handled 
by messages passed from task to task by the Root. In 
order to avoid copying of message text, memory mapping 
registers 5 ( '1 - 48K) and 6(*J8K - 56K) are used. A task 
wishing to send a message executes Trap 0, and upon 
return, tne Root nas set up mapping register 5 to point 



HEP OPERATING SYSTEM 



to an available message buffer and general register 
to address the buffer. The message buffer is a 128 byte 
area witn the following format: 



Byte 
Byte 



2 


Link 

Source Destination 


Byte 


4 


Priority 


Byte 
Byte 


6 
8 


Length 
Type 



10-127 



Data 



Tne message is transmitted by placing word of 
tne message in general register and issuing Trap 1. 
Tne Root locates the destination task using the DEST 
field of the message. 

Tasks 0-31 are dummy terminal tasks. 
Transmitting to these tasks causes the message to enter 
tne terminal service routines. These are described in 
tne next section. Tasks 32 and greater and are actual 
tasks. Task numbers for these tasks are determined by 
Disk Build. All real tasks have an input queue into 
which all messages sent to them are placed. Messages in 
the queue are maintained in priority order using tne 
priority field of tne message buffer. Wnen a task 
wishes to process a message, it issues Trap 2. If a 
message is waiting, mapping register 6 and general 
register are set up to point to the message and the 
task continues. If no message is waiting, the task 
enters Message Wait state and the Root dispatches the 
next ready task. After a task processes a message, it 
places the link field of the message in general 
register and executes Trap 4. This releases the 
message and places it in a list of available message 
buffers maintained by the Root. 



All message buffers are in the first 5 6 K of real 
memory. Tne link field of a message is the actual 
memory address of the message and is used by the Root 
to manipulate it. Mo error checking is performed by the 
Root in message nandling. If Executive task violates 
tne message protocol, a complete system crash will 
eventually result. Most message handling is performed 
by Executive task runtime library routines, but some 
tasks manipulate messages directly. Tnis is acceptable, 
but requires extreme care. 
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1.1.1.3 Terminal Service 

ASCII terminals connected to the Executive 
computer are handled by terminal service routines in 
the Root. Input to these terminals is assembled into 
messages and sent to appropriate tasks. Input messages 
are type 1 (Command). Output messages from Executive 
tasks which address tasks less than 32 are routed to 
the terminal service routines. Output messages should 
be type 3 (Display Text). The association between task 
numbers and terminals is compiled into the Root. By 
convention, task is the console terminal. 
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i s input 
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Since a task can generate lines of output much 
faster tnan a terminal can print them, the terminal 
output routines maintain a count of messages queued for 
printing by each task. Wnen a task has more than two 
messages waiting for printing, it is placed in Output 
Wait state. This is required to prevent a task doing 
multi-line output from consuming all the message 
buffers in the system. As messages are printed, the 
sending tasks are re-activated to generate further 
output . 



Certain terminal interfaces (DZ-M) are capable of 
programmed baud rate selection. Tnis is controlled by 
the use of Control-S and Control-Q characters in output 
messages. If a task sends Control-S to a terminal, the 
next cnaracter is used to set the baud rate, and tne 
terminal is placed in single-cnaraoter input mode. Each 
cnaracter typed is sent directly to tne controlling 
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task as a separate message. Normal mode is entered when 
a Control-Q character is sent to the terminal. 

The terminal service input routines interpret 
several characters for control functions. These are: 



Control-H 
Tab 



- Delete Last Character Typed 

- Insert Spaces to Next Multiple 
of 8 Columns 



Backslash - Delete Last Line Typed 

Control-S - Suspend Output 

Control-Q - Resume Output 

Carriage Return - Terminate Input Message 

All other control characters are ignored. 

1.1.1.4 I/O Interrupt Services 

Non-terminal I/O is performed directly by each 
Executive task. When device latency is short, tasks 
normally 'busy wait' en I/O completion. Where latency 
is long, the Root provides I/O interrupt support to 
enable a task to relinquisn the processor until I/O is 
complete. A task waits for I/O by placing the CSR 
a d dress of the device being used in general register 
and executing Trap 6. This causes the task to enter I/O 
Wait state until I/O is complete. 

The Root supports a specific set of I/O devices 
for interrupt. These are: 

Disk (CSR 176700) 
Tape (CSR 172522) 
Line Printer (CSR 177514) 

Other devices must be used without interrupts, 
except as described in Section 1.1.3 - Switch 
Interface . 

The interrupt service mecnanism in the Root 
records tne occurence of interrupts on tnr> supported 
devices, even if no task is in I/O wait for tnem. Thus 
a task may start I/O on a device, enabling its 
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interrupt, and subsequently issue Trap 6. If the device 
has already interrupted, the task will immediately 
continue, otherwise it will wait. Tnere is no timing 
requirement on the task's issuance of Trap 6 in order 
to detect the I/O complete. 

1.1.1.5 Miscellaneous Services 

The Root supports several other Trap codes and 
features associated with inter-task communication. 
These are: 

Trap 3 - Send and get buffer, 

(Trap 2 followed by Trap 0). 

Trap 5 - Free a buffer and wait for next buffer, 
(Trap 4 followed by Trap 2). 

Trap 7 - Test for input buffer waiting. 

General register set to if no buffer, 
set to non-zero if buffer waiting. 



Trap 8 



- Wait for 
(0-16 ras) 



next tick of the 60 cycle clock 



Trap 9 



Get task number of task whose two character 
ID is in general register 0. Task ID is 
returned in the low byte of register 0. The 
high byte contains the task issuing Trap 9. 
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1.1.2 Executive Debugger 

The Executive Debugger is a standard Executive task 
written in PASCAL. It differs from other tasks only in that 
it is linked as part of the Root, rather than being loaded 
from disk like normal tasks. The task ID for the Executive 

Debugger is 'XD' . 

The Executive Debugger may be used to examine and modify 
tne memory of other tasks and may set breakpoints in other 
tasks. It is also used by the Root to print error messages 
caused by Executive task malfunctions. The Executive Debugger 
is accessed from tne operator's console using a standardized 
command sequence. Command line syntax is as follows: 

{TYPE ID} {RANGE} . {TASK ID} <*VALUE> 

If tne "sVALUE" suffix is omitted, the specified item is 
printed, otherwise it is set to the entered value. 

Type ID is a single character describing the item to be 
examined or modified. Valid types are shown below. 



TYPE 

Blank or omitted 

A 

B 
C 



P 
From 



RANGE 

0-177776 

0-6 

0-7 



0-7 



MEANING 

Computer Memory Address 

Memory Address Mapping 
Regi ster s 

Breakpoint Locations 

Count of Waiting Output 
Terminal Messages 

Flag Showing Dispatching 
State 

Examine only, Continues 
Br eakpo int 

Head of Input Message Queue 
General Purpose Registers 
Processor Status Word 
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Range is entered as a single octal integer or pair of 
integers separated by a comma. For modify operations only the 
first range value is used; for examine operations, all 
locations between the two values are displayed. 

Task ID selects the task whose data is referred to. 
Task ID may be omitted when examining computer memory, and 
absolute locations are when referred to. Only locations in 
the first 40K of real memory may be accessed this way, and 
only for examine . 

Tne Executive Debugger is also used to print messages 
generated by error traps from other Executive tasks. These 
messages include the trap type, task ID, PC and status word 
of the trapping task. Trap types are: 

RS - Privileged Instruction (usually HALT) 

IL - Illegal Instruction or Nonexistent Memory 

OD - Odd Address 

MM - Memory Management Violation 

BP - Breakpoint 

EM - Emulator Trap (not used by this system) 

FP - Floating Point 

10 - IOT Trap (not used by this system) 

PF - Page Fault - Memory Management Error 

1,1.3 Switch Interface 

A major communications path between the HEP and 
Executive tasks is the switch interface. Tnis interface 
appears to the HEP as a set of 16 memory locations, of which 
tnree are presently used. A HEP memory access is broken into 
two parts - a request and a response. Tne switch interface 
generates a Root interrupt when a request is received, but 
does not generate a response. Responses are generated under 
software control of the responsible Executive task. 



In order to facilitate use of the switch interface, 
tnree small Ex ecutive tasks are incorporated into the Root. 
These tasks are activated by Root interrupt code wnen a 
switch request is received. They 7 read the contents of the 
switch request and send it to tne appropriate Executive task. 
These Root tasks are described on the next page. 
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1.1.3.1. Kernel Inbound Task (KI) 



Tne Kerne 
tasks wishing 
During HEP IPL, 
communications 
After saving it 
a word from the 
and issues no 
request, KI en 
an Executive 
processor, it 
message (Type 
area address 
issues Trap 10 
and activates 
data to the 
Ac tivate-Wj. th-R 
10. This caus 
from the PEM , 
response data . 
it to control m 
PEM issues an 
interrupt whic 
Reply message 
Wai t . T'ni s pr 
completed . At 
Release (messag 
KI via Trap 1 
issues Trap 2 
mechanism caus 
co-routines d 
provides an i 
interface wit ho 



1 Inbound Task is used by all Executive 

to send messages to the HEP Kernel. 

each PEM sends to KI the address of its 

area. This information is saved by KI. 
s address, the PEM then attempts to read 

switch interface. KI holds this request 

response. After receiving the read 

ters Message Wait state via Trap 2. When 

Task wishes to send a message to a HEP 

begins by sending a Seize with Reply 

13) to KI. KI places the communications 

for that processor in the message and 

(Reply). This places KI in Reply Wait 

the original sender. Tne sender writes 

communications area and sends an 

eply (message type 14) to KI via Trap 

es KI to respond to the outstanding read 

using the contents of the message as the 

The PEM process receiving the data uses 
essage processing. After processing, the 
other read request. This causes a Root 
h activates KI. KI generates another 

to the original sender and enters Reply 
ocess continues until the transaction is 

this point, the sender generates a 
e type 15) with no reply and sends it to 
0. KI frees the message with Trap *J and 
to get its next input message. Tne reply 
es KI and a HEP Executive task to run as 
uring HEP message transmission, and 
nterlock allowing sharing of the switch 
ut conflict between multiple senders. 



1.1.3.2 Kernel Outbound Task (K0) 



Tne Kernel Outbound Task handles unsolicited 
messages from the Kernel to the Batch Monitor Executive 
Task. During initialization, it enables interrupts on 
tne switcn location used for tnis purpose. Wnen an 
interrupt is received, it assembles tne switch data 
into a message and forwards it as a Switch Message with 
Reply (message type 12) to the Baton Monitor. When the 
Batch Monitor completes message processing, it replies 
to K0, and KO generates a switcn response, frees the 
buffer and reenables interrupts for the next 
unsolicited message. 
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1.1.3.3 Request File Task (RF) 

Tne Request File Task is similar to the KO task 
(in fact, most of the code is common) except that a 
different switch location is used and messages are sent 
to the File Manager rather than the Batch Monitor. The 
RF task is used for communications between HEP 
supervisor tasks and the file system. 



10 
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1.2 File Manager 

All disk I/O in the HEP System (except during IPL) is 
performed by the File Manager. Operations supported by the File 
Manager are : 

Logon - Validate User ID 

File Open - Locate an Old File or Create a New One 

Read a- Physical Record 

Write a Physical Record 

Obtain the Address of an Unused Physical Record 

File Close - Close, Delete or Rename a File 

In addition, operator commands exist to: 

Enter Debug Mode 

Leave Debug Mode 

Add a User ID 

Snut Down the File Manager 

For read/write operations, the File Manager merely performs 
disk control functions and data transfer on behalf of requesting 
Executive Tasks or HEP supervisor processes. For other 
cperaticns, tne File Manager performs directory search/update 
functions and search/update of the disk free section tables. 

1.2.1 Disk Format 

Tne system disk is a fixed sectored 3 0Mb moving head 
disk wi tn a 1.2 Mbyte/second transfer rate. Sectors are 512 
bytes (64 HEP words) long. 

1.2.1.1 File Format 

Files in the HEP system are a doubly-linked list 
of physical records. Eacn record contains two HEP words 
of linkage information, followed by 62 words of data. 
Tne linkage information is par to f the record and is 
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made available to and supplied by all software 
interfacing to the File Manager. The format of a 
pnysical record is snown in Figure A. 



WORD 



WORD 1 * 



WORD 2-6: 



THIS 



CYLINDER 



LAST 
CYLINDER 



THIS 



TRACK 



LAST 
TRJWCK 



THIS 



SECTOR 



LAST 
SECTOR 



NEXT 



CYLINDER 



USER 
NO. 



FILE 
NO. 
WITHIN 
USER 



NEXT 



TRACK 



NEXT 



SECTOR 



RELATIVE 
RECORD NO 
IN FILE 



DATA 



Figure A - DISK RECORD FORMAT 



Tne cylinder, track and sector information is used 
to chain records together. Maintenance of this 
information is the responsibility of Executive and 
supervisor tasks calling the File Manager - it is not 
en e eked or modified by the File Manager except during 
file accesses for internal File Manager purposes. 

Tne "next" fields of tne last record in a file 
contain all zeroes; similarly, the "last" fields of the 
first record of a file contain all zeroes. 



The user number , 
fields are used for 
system debug. .They 
Executive tasks and HEP 



file number and record number 
file consistency checking and 
should be maintained by all 
supervi sor s . 



Tne format of tne "this 



"next" and "last" fields 



is referred to as a "di skaddress" and is the standard 
format for representing disk locations. Each 
di skaddress occupies 32 bits (1/2 HEP word). 
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1.2.1.2 Directory Format 

In the HEP system, files are accessed via a 

tree-structured directory system. At the leaves of the 
tree are disk file headers. Eacn file header occupies 

one record, and contains complete information about a 

single file. The format of a file header is shown in 
Figure B . 



WORD 



THIS ADR. 


PREV. ADR. 


NEXT ADR. 


USER 
NO. 


FILE 
NO. 


RECORD 
NO. 


LEN 


CKSUM 


OCOUNT 


MOD.- 


DATE 


DATE 




AC DATE 


FREC 


LREC 


UFD 


FHP 


RECSIZE 


ACPRIV 


EOFW 


FLEN 


FILENAME 



Figure B - FILE HEADER FORMAT 



The format of word and word 1 of a file header 
is standard. These words are used to link all file 
headers for a particular user into a file named 
'HEADER'. Tnis file is automatically maintained by the 
File Manager. By reading tnis file, a user program may 
obtain the name and all pertinent characteristics of 
all of its files. The remaining fields in the file 
neader pertain to the specific file and are discussed 
below. 
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LEN - Tne length of the file name in bytes. 

CKSUM - The exclusive OR of all the character pairs 
in the file name. 



OCOUNT - The number of users who have this file open. 
If negative, one user has the file open, and 
additional opens are not allowed. 

MODDATE - A 48 bit field containing the date and time 
this file was last closed by a user with 
write access. The date is in standard system 
date format, described in Section 1.11 - 
Disk Builder. 

CRDATE - Date this file was created, in standard 
format . 

ACDATE - Date this file was last accessed. 

FREC - The diskaddress of the first record in the 
file. All files have at least one record, 
which may contain no data. 

LREC - The diskaddress of the last record of the 
file. 

UFD - The diskaddress of the UFD record pointing 
to this file. UFD records are discussed on 
the next page. This pointer is used during 
file delete/rename operations. 

FNP - Tne diskaddress of the file 'HEADER' for 
this user. Used for file delete/rename 
operations. 

RE C SIZE - Tne record size in HEP words of the records 
in this file. This in form a ton is not used by 
the File Manager, who deals in physical 
record s only. 



ACPRIV 



EOFW 



FLEM 
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Access privileges for this file. The high 
byte of the field controls public access 
privileges, while the low byte controls the 
users own access privileges. Bits in each 
byte are defined as follows: 



Read Access 
Write Access 
Extend Access 
Exclusive Access 
Semaphored Access (not used) 
Delete/ Rename Access 
Execute Access (not used) 
Access Change Access 



End of file word. The word number of the 
first free word in the last record of the 
file. All files must be an integral number 
of words long. All files must contain at 
least one word; for an empty file, 
FREC * LREC and EOFW x 0. If a file is an 
integral number of physical records long, an 
extra record is present at the end of the 
file, and EOFW * 0. 

Tne record number of the last record in the 
file (zero relative). 







1 






1 , 


• • * 


.. 1 




• • • 


. 1. 
1. . 




. . 1 




. 1 






1 , 







FILENAME - The 1 to 448 character name of the file. The 
filename is stored in a byte-swapped format 
within each word. Characters are in the 
order shown below: 



1 





3 


2 


5 


i| 


7 


6 



Tnis is a consequence of the way the 
Executive computer (a PDP-11) addresses 
bytes. 
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In order to speed up searching the file 
directories, an indexing file, called the User File 
Directory, or UFD, is maintained for each user. This 
file resides in the directory of the distinguished user 
whose ID is '000000000000'. The name of this file is 
UFD. XXXXXX, where XXXXXX is the ID of the user in 
question. The format of the records in the* UFD file is 
snown in Figure 0(a) and Figure C(b). 



WORD 



WORD 1 
WORD 2 
WORD 3 



WORD 6 3 



THIS 


NEXT 


LAST 


COUNTS 


LEN 


CKSUH 


FHA 


LEW 


CKSUM 


FHA 


• 


LEU 


CKSUM 


FHA 



Figure C(a) - UFD ENTRY FORMAT 









TRACK 




LEN 


CKSUM 


CYLINDER 


FHA 


SECTOR 



Figure C(b) - UFD ENTRY FORMAT 



Tne LEN and CKSUM fields in a UFD entry are 
duplicates of tne corresponding fiolds in the file 
neader to which it refers. The FHA field is the 
diskaddress of tne fileheader for the file. When 
searching for a file, tne File Manager need only read 
the file neaders of files with corresponding length and 
checksum fields. Since 6 2 files may be 'referred to per 
UFD record, a considerable saving in open time results. 
Tne UFD is automatically maintained by tne File 
Manager, and is not visible or accessible to the user. 
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In order to permit access to files from multiple 
users, the User File Directories are pointed to by a 
higher level directory called the Master File Directory 
or MFD. This file is also held under the distinguished 
ID '000000000000 » . The format of an MFD record and MFD 
entry is shown in Figure D(a) and Figure D(b) . 



WORD 
WORD 1 
WORD 2 
WORD 3 



WORD 62 
WORD 63 



THIS 


NEXT 


LAST 


COUNTS 


USER 


ID 


UFDA 


• 
• 


USER 


ID 


UFDA 



Figure D(a) - MFD RECORD FORMAT 



USER ID 



CYLINDER 



TRACK 
UFDA 



SECTOR 



Figure D(b) - MFD ENTRY FORMAT 



The user ID is a 12 cnaracter (padded witn blanks) 
cnaracter string in byte-swapped format as described 
for file names. The diskaddress points to tne first 
data record of tne corresponding UFD. Eacn user in tne 
system nas a single MFD entry. 
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Trie UFD's and MFD are maintained as files by th.e 
File Manager. Access to their data is not made by 
normal file access mechanisms. Tne File Manager 
searches and updates these files using internal 
routines not available to other tasks. The MFD, the UFD 
for the distinguished user, and ether files are built 
by Disk Build during disk initialization. 

1.2.1.3 Bitmap and Reserved Sector Format 
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The File Manager maintains the bitmap record for 
one cylinder in core at all times. All requests for 
records are allocated from this cylinder until it is 
full. At this point, the File Manager moves to the next 
hi g nest cylinder (modulo tne maximum valid cylinder) 
until available sectors are found. Thus bitmap I/O is 
minimized, and all files being extended at the same 
time will go on the same cylinder if possible. This 
reduces disk latency and improves performance. 

Cylinder 0, track 0, sectors and 1 are unique in 
that tney are marked allocated in the bitmap, but are 
net part of any file. Sector is the hardware 
bootstrap, and is described in conjunction with tne 
Disk Builder. Sector 1 is the File Manager and IPL 
pointer sector. 



Tne THIS field of sector 1 points to tne first 
data record of the MFD. Tne LAST field of sector 1 
points to tne bitmap. Tne data portion of sector 1 
contains pointers to IPL files and is described with 

Disk Build. 
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\.2.2 Basic File Management Routines 

1.2.2. 1 OBTAIN 

OBTAIN is used to get an unallocated sector in 
wnich to write data. Tne sector is marked allocated by 
OBTAIN. 

1.2.2.2 LOOKUP 

LOOKUP is used to search a user file directory for 
a specified file. If the lookup is successful, the file 
header of the file is made available to the caller. 

1.2.2.3 LOGON 

LOGON is used to locate a specific user file 
directory. If the logon is successful, the diskaddress 
of the UFD is made available to the caller. 

1.2.2. 4 ENTER 

ENTER is used to add a file header to a specified 
user file directory. An initial data record is 
allocated and initial values in the file header are 
supplied. No duplicate file checking is performed. 

1.2.2.5 ADDUFD 

ADDUFD is used to create a UFD and enter it into 
the MFD. It is only activated under operator command. 
No duplicate UFD checking is performed. 

1.2.2.6 RELEASE 

RELEASE is the opposite of OBTAIN, and is used to 
free sectors in the bitmap when files are deleted. 

1.2.2.7 DELETEFILE 

DELETEFILE is used to remove a file header from a 
UFD, delete the file header record, and queue the file 
data records for deletion. Since tnis process may be 
lengthy, it is handled as a 'demon' during otherwise 
idle File Manager time. 
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1.2.2.8 RENAMEFILE 

RENAMEFILE updates a UFD and file header to 
contain a new name. Note that only the name of a file 
can be changed, not its owning UFD. 

1.2.3 Executive Interface 

Executive tasks communicate with the File Manager using 
the standard system message mechanism. Several message types 
are processed: 



TYPE 


MEANING 


6 


File Open 


7 


File Close 


8 


Record Read 


9 


Record Write 


10 


Obtain a Sector 


1 1 


Logon 



A common message format is used for open, close, 
road and write. Tnis format is shown in Figure E. 



16 Bit 
Word 



1 

2 

3 
n 

5 
6 
7 
8 

23 


UID 




RQ TYPE 




BUFAD 




BASE 




OPLEN 




STATUS 




ACCESS 




OPTION 
CHARACTERS 



Figure E - OPEN/CLOSE MESSAGE FORMAT 
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Tnese fields are used as follows: 

UID - Diskaddress of user's UFD (open, 

close) . 
Supplied by caller. 

RQ TYPE - If 0, open for output. 

If nonzero, open for input (open, 

close) . 

Supplied by caller. 

BUFAD - Address in caller's space of disk 

record (open, close, read, write). 
Supplied by caller. 

BASE - Base of user stack div 6*4, (open, 

close, read, write). 
Supplied by caller. 

OPTLEN - Length of option characters (open). 

Supplied by caller. 

STATUS - Result of operation (open, close, 

read , write ) . 
Set by File Manager. 

ACCESS - Requested access codes 

(open, close) 

for tnis open -set by File 
Manager. Based on option string on 
open. 
Supplied by caller on close. 

OPTION CHARACTERS - ASCII characters specifying 

( open , close ) . 
Open or close options 
Va 1 id options are : 

/!•/ s Write Access 

/R = Read Access 

/A r Append Access (extend plus 

position to end of file) 
/T * Temporary File 
/ M * New File (delete old if 

present ) 
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Option processing is provided as a service to 
Executive Tasks. Not all option bits are used by the 
File Manager. Positioning to end of file (/A) and file 
close (/T) are the responsibility of the 
are set in ACCESS to indicate these 
specified, but action in these options 
by the caller. The low byte of ACCESS has 

the file header. The 



deletion on 
caller. Bits 
options were 
must be taken 



tne format described for ACPRIV in 
nigh byte is as follows: 



1 



Temporary (/T) 



1 . Append ( /A) 

1. . New (/N) 



All message communication with the File Manager 
uses the Root reply mechanism, and the File Manager 
responds to Executive requests via Trap 10 (Reply), 



1.2.3.1 Executive Open 

An Executive task ope 
message 6. The BUF AD field of 
disk record. In this record 
RE C SIZE fields are supplied 
only used if the file is to b 
may contain a user ID in squar 
and may contain access optio 
end. Access options are only u 
created. The open routine USE 
and options. If the user I 
Manager uses LOGON to locate tn 
diskaddress in the open mes 
options are processed into the 
is file header, and LOOKUP and 
and/or create the file. Ace 
from the processing of the m 
stored in the message ACCESS f 
ACPRIV in the file header, 
requested the actual disk file 
callers disk record, and tne 
0. If not, the message status 
header is not supplied. 



ns a file by issuing 
the message points to a 
, the FILENAME, LEN, and 
by the user (RECSIZE is 
e created). The FILENAME 
e brackets at the start, 
ns in parenthesis at the 
sed if the file is to be 
ROPEN strips the user ID 
D was present, tne File 
e UFD, otherwise the UFD 
sage is used. The access 
ACPRIV field of the user 
ENTER are used to locate 
ess privileges resulting 
ess age option string are 
ield and checked against 
If valid privileges are 
neader is written to the 
message status is set to 
is non-zero and the file 



Tne format of tne access code string following tne 
file name is; (PRWEXD, URWEXD) where the string 
beginning with f P' denotes public access privileges and 
tne string beginning witn ' U' denotes user access 
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privileges. Any or all of the access characters may be 
suppl ied : 

R - Read Access 

W - Write Access 

E - Extend 

X - Exclusive 

D - Delete/Rename 

Tnese characters determine the permanent access 
attributes of the file if it is created by open. 

Error returns from open are given in Table F. 

STATUS ERROR 



-64 
-65 
-66 

-69 
-70 
-7 1 
-68 



Nonexistent User ID 

Bad Message Options 

File Existence Conflict 

(duplicate file or nonexistent file) 

Requested Access Denied 

Exclusive Access File Already in Use 

Disk I/O Error 

Attempt to Create File in Another UFD or 
other Enter Failure. 



Table F 



OPEN ERROR CODES 



1.2. 3*^2 Executive Close 

An Executive task closes a file by issuing 

message 7. Tne format of tne message is as indicated 

previously. The file neader pointed to by BUFAD must 

contain the d i s k a d d r e s s of tne file neader to be closed 

in tne 'THIS' field. If tne first character of the 

option field in tne message is •D* the file will be 

deleted. . If tne first cnaracter is , R I , tne file will 



-> o 



HEP OPERATING SYSTEM 



be renamed and the LEN and FILENAME portions of the 
file header must contain the new name and its length. 

Error codes from CLOSE are given in Table G. 

STATUS ERROR 



-18 

-19 
-17 



Delete or Rename Not Done - 

Access Violation or File Open by Other Users 

(delete only) by Other Users (delete only). 

New Name is Duplicate (rename only). 

I/O Error 



Table G - CLOSE ERROR CODES 



1.2. '3. 3 Executive Read/Write 

Executive tasks read and write records via 
message 8 (read) and message 9 (write). Only the BUFAD 
and BASE fields are used in these messages. Data is 
read from or written to the diskaddress specified by 
tne f THIS' field of the record pointed to by BUFAD. No 
checking is done on the validity of the address or 
anything else. This is the responsibility of the 
calling task. 

1.2.3.4 Executive Obtain 

If, wnile extending a file, an Executive task 
requires an additional disk record, it issues message 
10. Tne File Manager uses the OBTAIN routine to 
allocate a sector, and the diskaddress of the sector is 
returned to the caller in the first 32 bits of the data 
portion of the message. 



1.2.3.5 Executive Logon 



File 



Several 
specify the diskaddress 
obtained via message 11. A 
twelve character user ID of a 
bytes of tne data portion 
Manager use3 tne LOGON routine 



Manager calls require the caller to 
of a UFD. Tnis address is 
calling task places the 
user in the first twelve 
of the message. The File 
to reacn the MFD for tne 



UFD address. If successful, the diskaddress of the UFD 
is returned in the first 32 bits of tne message, 
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replacing the first 4 characters of the user ID. Logon 
error code s are: 



STATUS 



MEANING 



-19 



No Such User ID 



1.2.4 Resident Supervisor Interface 

Tne File Manager provides I/O services to HEP processes 
in much tne. same way as it does for Executive Tasks. For 
Executive tasks, I/O is performed directly into tne caller's 
buffer. Since HEP data memory is not part of the Executive 
computer's address space, HEP I/O is handled differently. 

HEP requests arrive via the Unibus-to-Swi ten Interface 
and the File Manager's helper task RF. The message received 
by the File Manager is a switch message (message 12) and 
contains one HEP word of data. The high 16 bits of the data 
word are a request code type with the following values: 

- Logon 

1 - Open 

2 - Close 

3 - Read Record 

4 - Write Record 

5 - Obtain Record 

Tne low 32 bits of the word point to a 66 word I/O 
block. Tne last 64 words of this block are a disk record in 
tne format previously discussed. Tne first two words contain 
I/O parameters and options. Tnese words are described below. 



CODE 


STAT 




UID 








E 


D 






A 


64 WORD DISK RECORD 



Figure H - HEP I/O REQUEST FORMAT 
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CODE - Request code, as enumerated above 

STAT - Result status supplied by File Manager. Values as 
indicated for Executive Requests. 

UID - Diskaddress of user file directory (open, close). 

A - Requested access privileges, format as shown in 
Table C (open, close). 

D - File* history ( open ,c lose ) . Possible values are: 

- Use Old File if Present, 

Else Create Mew File 

1 - Delete Old File if Present, 

Create New File 

2 - Use Old File 

3 - Create New File 

Fail if Old File is Present 

E - File Disposition (close). Possible values are: 

1 - Delete File 

2 - Keep File 

5 - Rename File 



Trie File Manager reads tne I/O block into a local buffer 
U3ing tne low speed bus (LSB) Interface to HEP data memory. The 
amount of data read depends on the request code in the switch 
message. After performing the request, all or part of the I/O 
block is written back to data memory witn the LSB. Since the 
LSB is shared with other Executive tasks, the File Manager 
becomes uninterruptable during this transfer. 
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1.2.4.1 The Resident OPEN 

A HEP supervisor opening a file does so by building 
a dummy file header in the I/O block. For old files, the 
file name and name length are required. The file name 
must be stored in byte swapped format as previously 
described. For newly created files, the RECSIZE and 
ACPRIV fields must be supplied. Unlike Executive opens, 
no option processing is provided. The only optional 
function is the provision of a user ID in square brackets 
at the start of of the File name. 

If tne open is successful, the File Manager copies 
the file header into the I/O block. 

1.2.4.2 Resident CLOSE 

Resident CLOSE is the same as Executive CLOSE except 
that the file disposition field is used to determine 
close action . 

1.2.4.3 Resident READ/WRITE 

Resident I/O is the same as Executive I/O. The 
'THIS' field of the disk record in the I/O block is used 
to determine the diskaddress. 

1.2.4.4 Resident OBTAIN 

Resident OBTAIN uses the standard OBTAIN routine to 
allocate a disk record. The address of the record is 
returned in the 'NEXT' field of the disk record in the 
I/O block. 

1.2.4.5 Resident LOGON 

Resident LOGON obtains tne 12 character user ID from 
tne first 12 bytes of the disk record in tne I/O block 
(word 2 and the high naif of word 3). The user ID must be 
byte swapped. The diskaddress of the UFD is returned in 
tne UID field of tne I/O block (second half of word 0). 

1.2.5 Operator Interface 

Tne operator may send messages to tne File Manager from 
tne console terminal. Tne supported messages begin witn a 
single character, as snown on tne next page: 
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D - Toggle tne debug switch. Wnen debug is on, all received 
messages are listed on tne console in octal. 

Z - Snut down. Tne bitmap is written to disk and the File 
Manager executes a halt. No files are closed, and the 
File Manager may be restarted with the Executive 
Debugger (XD). If a file is being deleted when Z is 



entered, the message 



BUSY 



will result and the File 



Manager will not shut down. 
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1.3 PASCAL Runtime Library 

Tne PASCAL Runtime Library provides the interface between 
PASCAL READ, WRITE and associated I/O statements and the file 
manager. Components of the PASCAL runtime are linked into all 
Executive tasks. In addition to I/O, the PASCAL runtime provides 
the basic runtime environment and service subroutines for PASCAL 
tasks . 

1.3.1 PASCAL Interface 

The PASCAL runtime supports a set of I/O calls similar 
to that provided by standard PASCAL. Certain unneeded 
capabilities are not supported, and several extensions have 
been made. 

Supported text output procedures are: 

WRITE(CHARrN) Write the character CHAR to the file F or to 
WRITE(F,CHAR:N) OUTPUT, followed by N-1 blanks. 



WRITE(I:N) 
WRITE(F,I:N) 



Write integer I as a decimal string to the 
file F or to OUTPUT, followed by blanks to a 
total width of N. If N is negative, write I 
a s an octal string . 



WRITE(S:N) 
WRITE ( F, S:N) 



WRITELN 
WRITELN(F) 



Write the character string S to F or to 
OUTPUT followed by blanks to a width of N 
characters. If N is less than tne length of 
S, S is truncated. S may be a literal string. 

Terminate a 1 ine . 



BREAK(F) 



Terminates a line but does not advance 
carriage to a new line. 



Multiple I/O items may be combined in a WRITE request. 
If WRITELN is used with output arguments, the line is 
terminated after the last item. 

Real and boolean output are not supported. 
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Supported text input procedures and functions are: 



READ(CHAR) 
READ(F,CHAR) 

READ(S) 
READ(F.S) 



EOLN(F) 



EOF(F) 



Read one input character into CHAR from F or 
input . 

Read a string of input characters into S from 
F or INPUT. If the current line is exhausted 
before filling S, pad with blanks. 

A boolean function which is true if the next 
character to be read is the end-cf-line 
character . 

A boolean which is true when there are no 
more characters to be read. 



READLN 
READLN(F) 



Discard remaining characters in the current 
line (if any) and point to first character of 
next line. 



Multiple I/O items may be combined in a READ request. If 
READLN is used with input arguments, the rest of the line is 
discarded after tne items are filled. 

Integer, real and boolean input are not supported. 

Tne standard procedures GET and PUT may be used with text 
and non-text files. When used with a file connected to a 
console, GET exnibits non-standard behavior. Tne PASCAL 
standard requires tnat the first cnaracter of input be present 
immediately after a READLN. In this implementation, the first 
cnaracter is not present until a GET or READ operation is 
performed. Tne first GET consumes a dummy blank character. This 
cnaracter is not provided by READ; character strings consumed 
by READ contain only actual input text. 

Wnen used with non-text files, the record definitions 
acceptable to GET and PUT are restricted. Tne following record 
sizes are accepted: 

<= 1 36 Bytes 
2 4 8 Bytes 
496 Bytes 
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Other 
present in 



sizes would require data blocking facilities not 
the runtime routines. 



The standard procedures RESET and REWRITE nave been 
extended to allow opening specific disk files by name. Tne 
syntax of these procedures is as follows: 

RESET(F, NAME, OPT IONS, V) 
REWRITE (F, NAME, OPTIONS, V) 

RESET is used to refer to a pre-existing file, while 
REWRITE causes the creation of a new file. The parameters are: 

F Name of the PASCAL file variable controlling this 
file. 

NAME A character array or literal string containing 
the file name. If omitted on a RESET, the file 
presently open is rewound. If name is a character 
array, the file name must be non-blank and padded 
to the right with blanks. 

OPTIONS A character array or literal string containing 

option characters. Each option is a slash 

followed by a single character. Available options 

are : 

R-Read Access 
W - Write Access 
A - Append Access 
T - Temporary File 
N - Force New File 



If OPTIONS 
supplied . Foi 
REWRITE, /W 
defaults . 



is omitted, 

RESET, /R 

and extend 



default options are 
is the default. For 
permissions are the 



Integer variable. On entry, contains tne record 
length to be associated with the file if the file 
is created. This may differ from the record size 
of tne file variable. Tne file i3 processed based 
on the file variable if non-text, but the line 
length is is taken from V if the file is text. V 
is in HEP words (multiples of 8 bytes). On return 
from RESET/REWRITE, V contains open status. If 
V<0, tne open failed and the value is tne errcr 
code. If V>sO, it is tne record size of tne file, 
in HEP words. 
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Files may be closed, renamed or deleted by calls to the 
PASCAL procedures. 

CLOSE(F) 

RENAME(F, NAME, LEN) 

DELETE(F) 

CLOSE(F) is a standard procedure and may be used to close 
any file. RENAME and DELETE are nonstandard external procedures 
and must be declared with external declarations of the form: 

PROCEDURE RENAMECVAR F:TEXT;VAR NAME : <CHA RACTER ARRAY TYPE>; 
LEN; INTEGER). 
EXTERNAL; 

PROCEDURE DELETE(VAR F:TEXT); 
EXTERNAL 

F may be declared to be another type than TEXT, but the 
declaration must agree with the file type to be renamed or 
del eted . 

Files will also be closed if a RESET or REWRITE is issued 
for tneir file variable specifying a new file name. 

1.3.2 PASCAL Runtime Environment 

A PASCAL Executive Task is loaded by the ROOT in a 
standard fasnion. Of the 8 memory pages, the first four are 
reserved for code. Page 7 is mapped to I/O space. All PASCAL 
variables and working space is located in page 4. The first 
locations in thi3 page, starting with location 100000. (octal) 
are used for control information. Tnis information is shown in 
Figure 1.3.1. 
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MNEMONIC 
LOCATION 

$KOREx 100000 

$FREE=100002 

$RESR5*100004 
$RESR6*100006 
$NEWLN*100010 

$FIL3F=100012 
$FILTB*100014 
$LOGCY* 100016 
$LOGDA= 100020 
$FILE=100022 
$3 PACE *10002'» 
$FMTSKx100026 
$MLENs1 00030 
$SINPa100032 
$SOUTP= I 0003^ 
$HEAP= 100036 



MEANING 

; Top of Heap Space, Base of Stack Space 

; Start of Linked List of Free Blocks of Length 
$NEWLN • 

; INITIAL R5, SAVED BY MAIN 

; INITIAL R6 

; Length of Storage Manipulated by New and 
Dispose 

Start of Linked List of Free File Buffers 

Start of Linked List of Free File Variables 

Users UFD Location (CYL) 

Users UFD Location (Track, Sector) 

File Variable Address Address 

Dummy Blanks for Get Processing 

Task ID of File Manager 

Length of Last Queue Message 

Standard Input File Variable Address 

Standard Output File Variable Address 

Start of Heap Space 



Figure 1.3.1 - PASCAL WORK AREA BASE 



In a running PASCAL task, the register SP points to local 
variables, and register R5 points to the global variables. 
During initialization, file variables are allocated in tne 
locations following $HEAP. Tne number of file variables is a 
ccmpile-time parameter, normally 6. $K0RE is set to point 
immediately after tne file variables, and SP is set to point to 
location 120000, the top of page U . Tne file variables for 
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In operation, local variables of procedures use the stack, 
wnich grows downward from location 120000. Calls to NEW use the 
Heap, wnich grows upwards from the top of the FDBs. If these 
two areas collide, unpredictable runtime errors will occur, and 
tne program must be recoded to use less storage. 

1.3.3 Files and File Variables 

Several types of files are supported by the PASCAL 
runtime. Tnese are divided into text and non-text files. 

1.3.3.1 Non-Text Files 

Non-text files are accessed via GET and PUT, and must 
reside on disk. These files may be word or record files, as 

described below. For these files, the amount of data 
transferred by a GET or PUT is strictly determined by the 
file variable record size. The runtime is only capable of 
handling spanned records if tne record size is less than 
1? HEP words, whicn is wny the record sizes are restricted. 

Record files consist of a sequence of fixed length 
records, each an integral number of HEP words long. .Word 
files nave no external record structure and are normally 
processed a word at a time. Tne PASCAL Runtime ignores word 
or record structure for non-text files, treating them as 
record files with tne record lengtn determined by tne file 
variable. A permanent record length may be specified by 
REWRITE wnich need net agree witn tne file variable size. 



34 



HEP OPERATING SYSTEM 



1.3.3.2 Text Files 

Text files are of tnree types: console or queue files, 
word files on disk and record files en disk. 
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rd text files contain variable length ASCII text 
All lines contain a multiple of 8 characters, and 
ded with blanks ifnecessary to become a multiple of 
ce ASCII characters contain only 7 bits of data, the 
it of the first character of a line is used to 

lines. Lines span physical record boundaries, 
ation of the sign bit is an automatic function of 
ntime library, and data visible to tne using program 
ontains a set sign bit. Since the Executive computer 
bytes right to left, while tne HEP packs left to 

the runtime library performs a byte swapping 
on on every physical record of word text files. Tnis 
e on both input and output so that disk data is 
in HEP (left-to-right) order. The runtime pads lines 
railing blanks on read string operations, but does 
ip trailing blanks on write string operations. Tnere 
estrietion on line lengths in word text files. 



Record text files contain fixed lengtn ASCII text 
lines. All lines contain the same number of characters, 
wnich must be a multiple of 8. Lines may span physical 
record boundaries. All <? 5 6 possible characters may occur in 
a record text file. Record lengths may not exceed 
488 bytes. Output to a record text file will be truncated 
or padded witn blanks as required to fit the record size. 
Input will be padded with blanks as truncated on read 
string operations. Byte swapping on input and output is 
performed to force disk <inta to be in HEP format. 
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BIT VALUE 

NAME (OCTAL) MEANING 

S.EOF 100000 File has reached EOF. 

S.EOLN 40000 Text file is at EOLN on input. 

S.LAST 20000 Disk file is in the last physical 

record . 

S.TXT 10000 File is a text file. 

S.ERR 4000 Error encountered while processing 

file. 

S.WAIT 2000 Queue or console file requires a 

physical read before supplying data. 

S.END 1000 Output disk file has terminated a line, 

but not started a new line. 

Table 1,3.3 - FILE VARIABLE STATUS BITS 

Trie saved pointer field (V.SVP) is used if V.PTR is 
pointing to a space at end of line in order to locate the 
next actual data character. 

V.BUF points to the start of the current logical 
record for a non-text file, or to the start of tne buffer 
for a text file. If a logical record is spanned, V.BUF 
points to tne psuedo- start of trie logical record preceding 
tne actual I/O buffer. V.BUF is advanced by each PUT orGET 
operation. For console files, V.BUF points to the first 
cnaracter of data. 

V.LEN contains the record length to be used for this 
OPEN of tne file. For text files, this number is -1. V-.LEN 
is determined by tne size of tne record declared in tne 
user's PASCAL program. 

V.FDB points to tne file descriptor block for tnis 
file. For a console file, V.FDB is 0. Tne I/O control block 
is described in the next section. 

V.EOB points to tne end of valid data in tne I/O 
control block. Normally, tnis is tne end of tne pnysical 
record, but on tne last record of the file, V.ECB points to 
tne end of tne data. For console files, V.EOB points to the 
end of tne message. 
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1.3.3.3 File Variables 

A file variable occupies 7 16 bit words in trie 
Executive Computer. File variables are compiled into the 
runtime library. The number of file variables which may be 
simultaneously active is a compile time parameter in the 
runtime. An Executive task may have many files declared, 
but only a limited number of these may be simultaneously 
open. Tne RESET/REWRITE procedure establishes a pointer in 
the user's variables to the actual file variable. The 
format of the file variable is shown in Figure 1.3.2. 



ADDRESS 







V.PTR 


2 


V.STAT 


4 


V.SVP 


6 


V.BUF 


10 


V.LEN 


12 


V.FDB 


1 n 


V. EOB 



Pointer to Current Character or Record 

Status Bits 

Saved Pointer 

Start of I/O Record 

Record Length (-1 if Text File) 

Pointer to File Description 
(0 for Console File) 

Pointer to End of File I/O Buffer 
Figure 1.3.2 FILE VARIABLE 

V.PTR always points to the current character in a text 
file, or to a reserved location containing a blank, if the 
text file is at EOLN. For non-text files V.PTR points to 
tne start cf the record, either in the current I/O block, 
or to a work area used to collect spanned records. 

Tne low byte of V.STAT contains the destination task 
number if the file is a queue or console file, and is 
unused otnerwise. The high byte of V.STAT contains status 
bits, defined in Table 1.3.3. 
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1.3.3.4 File Descriptor Block 



All disk files require a file descriptor block. A 
fixed pool of FDBs is created during PASCAL initialization, 
and disk file OPEN's in excess of the pool size cannot be 
accommodated. Tne format of an FDB is shown in Figure 1.4. 

WORD 



PHYSICAL 
RECORD BUFFER 




512. 



516. 



518. 



520.- 
655. 



DISKADDRESS OF 
FILE HEADER 



ACCESS 
PRIV 



EOF WORD IN 
LAST RECORD 



SPANNED RECORD 
WORK AREA 



Figure 1.3.4 - FILE DESCRIPTOR BLOCK 

1.3.4 Miscellaneous Runtime Support Routines 

Several utility routines are included in the runtime 
package. These are described below. 

1.3.4.1 FINIT 

Decla ration : 

PROCEDURE FINITCNFDB, NEWSrZE: INTEGER) 

FINIT is called once by every main program 
to define the number of FDBs and the size of the 
area returned by NEW. 
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1.3.4.2 LOGON 

Declaration : 

FUNCTION LOGONCVAR UID: ARRAYCO . . 1 1 ] 
OF CHAR) 

LOGON invokes the file manager to logon as 
the user UID. If successful, the locations USERDA 
and USERCY in the runtime base are set up to 
point to the UFD. If logon is successful, LOGON 
returns TRUE, else FALSE. 

1/3.4.3 LINLEN 

Declaration : 

FUNCTION LINLEN: INTEGER 

LINLEN returns the length of the last 
console input line. 

1.3.4.4 SETID 

Declaration : 

PROCEDURE SETID(F:TEXT;TSK: INTEGER) 

SETID sets the destination of the console 
file F to TSK. 

1.3.4.5 GETTSK 

Dec lar a tion : 

PROCEDURE GETTSK(VAR N:INTEGER); 

GETTSK obtains the task number of the task 
whose two-character ID is placed in N. Tne value 
is returned in N as two bytes. The low byte of N 
is the task number of the requested task. The 
high byte is tne task number of the task calling 
GETTSK. 

1.3.4.6 ERR 

Declaration : 

FUNCTION ERR(F:FILE OF ...) I BOOLEAN 

ERR tests the S.ERR bit in V.STAT of tne 
file and returns TRUE if an error nas occured , 
otherwise FALSE. 
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1.3.4.7 GETLOC 

Dec laration : 

PROCEDURE GETLOC(VAR F:TEXT;VAR L: 
ARRAYCO. .4]OF INTEGER); 

GETLOC returns the present file position in 
tne file F. This information may be used in a 
subsequent call to SETLOC. 

1.3.4.8 SETLOC 



Dec laration 



PROCEDURE SETLOC(VAR F:TEXT;VAR L: 
ARRAYCO. .4]0F INTEGER); 



SETLOC sets the file position of F to the 
information contained in L. SETLOC may only be 
used for word files with read access only. The 



information 
pr esentl y 
information 
tne call to 
f ai lur e . 



in L must correspond to the file 
open as F. Alteration of the 

in' L between the call to GETLOC and 
SETLOC will probably result in system 
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1.4 Tape Manager 

1.4.1 Overview 
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Tape Manager runs as a task under the Executive and 
all tape handling functions. The task may be 
from the operator's console. Commands to 
over files, and position to end of volume (end 
file) are supported. Individual files may be 
from tape, and entire UFDs may be dumped to or 
tape. The Tape Manager reads and writes the 
directly by manipulating the appropriate I/O 
n tne PDP. 
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last 
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1.4.2 Tape Format 



Two format modes are supported for data on tape: record 
mode and dump mode. 

1.4.2.1 Record Mode 

In record mode each physical tape record contains 
one logical record as defined when the disk file was 
created. The file is terminated on tape by a file mark. 
Record mode format is created only when an explicit file 
name is specified to be copied and the file is defined to 
be of record type. Record mode format may be read only by 
explicitly specifying a file name, and results in the 
creation of a record type disk file whose logical record 
size is defined to be the length of the tape record read. 
Tn ere fore it is not necessary (or possible) to supply a 
record size in the command to the Tape Manager. 

1.4.2.2 Dump Mode 

Dump mode format is used for copying word type files 
and for dumping and restoring UFDs. In dump mode each 
pnysical tape record is 514 bytes long, except for the 
last record in a file, which is a short record. Dump mode 
format is created either by explicitly specifying a file 
wnich was created as a word file (logical record 
length * 0) or by requesting a UFD dump (dump all files 
in tne specified User File Directory). 
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1.4.2.2.1 Word Files 

In the case of copying a specific word 
file, each 514-byte tape record contains a 
physical disk record, including the 16-byte 
block header and followed by 2 bytes whose 
content is undefined. The last, short record 
contains the last physical disk record 
including header, truncated to 2 bytes past the 
end of the actual file data. Therefore the 
length of tne short record is always 2 bytes 
more than a multiple of HEP words. In the case 
wnere the actual file data exactly fills a 
physical disk record, the short tape record 
following the last block will be 18 bytes long 
(16-byte header plus 2 trailing bytes). The 
file is terminated on tape by a file mark. 

1.4.2.2.2 UFD Dumps 

The first record of a UFD dump is an 
identifying record containing the ASCII 
UID (User Identification) in the first 12 
bytes. The high byte of the UID has its sign 
bit set to mark this file as a UFD dump. The 
remainder of the record is undefined. Following 
the UFD identifying record are all the header 
records (from file HEADER for this UID) except 
the header record for file HEADER. Tnese 
records are used to identify tne files 
contained in the dump. Each header record is a 
pnysicnl disk record, including the 16-byte 
block header, followed by 2 undefined bytes. 
Following the last header record is a short 
record, 18 bytes long, which indicates the end 
of header records. The content of each file in 
the UFD follows, in the same order as the 
header records. Regardless of defined logical 
record length, each file in the dump has the 
same format on tape as a word file. En ah tape 
record contains a physical disk record, 
including the 16-byte block neader and followed 
by 2 bytes wnich in tnis case contain the 
defined logical record length. The last record 
in eacn file is a short record, indicating the 
end of the file. Tne last file in the dump is 
followed by a file mark which indicates the end 
cf tne dump for tnis UFD. If multiple UFD's 
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were specified, the next UID follows the file 

mark . 



1.4.2.2.3 End of Volume 



singl 
mark , 
This 
Tape 
po sit 
files 
.wr i t i 
file 
marks 



Following the last file on a tape (either 
e file or UFD dump) is an additional file 
resulting in two consecutive file marks, 
indicates the end of data on the tape. The 
Manager will not allow reading or 
ionihg past the double file marks. More 

to tape, resulting in 
file mark. The new last 
by two consecutive file 



may be written 
ng over the second 
is then terminated 



1.4.3 Command s 

Tne Tape Manager is accessible only from the operator's 
console, directed by commands in the form of messages 
prefaced by 'MT:' (the task ID for the Tape Manager). A 
command may specify tape positioning only, may direct that 
the tape be either read or written with a string of one or 
more file names or UIDs, or may direct the Tape Manager to 
read commands from a file. 

1.4.3.1 Tape Positioning 

Each tape positioning command is prefaced by a 
slash ('/') to distinguisn it from a file name. The 
command mnemonics and corresponding operations supported 
are as f o 1 lows : 



1 /RW 
1 /AP« 



' /FFn' 



- Rewind; positions tne tape at load point* 

- Append; positions the tape at the second of the 
two consecutive file marks which indicate end 
of volume; at this point, more files may be 
written to the tape, overwriting the second 
file mark and resulting in a new end of volume. 

- Forward file; positions tne tape immediately 
past the ntn file mark forward from the tape's 
current position; if n is not specified, 1 is 
assumed; if end of volume is encountered, the 
command is terminated leaving the tape 
positioned tne s^me as for '/AP 1 . 
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Multiple tape positioning directives may appear in a 
single command line; each leading slash serves as a 
delimiter. Eacn directive is performed in order, left to 
r ignt . 



Exampl es : 
! MT:/AP' 



- Positions the tape at end of volume. 



'MT:/RW/FF2' - Positions the tape at the start of the 
third file or dump on the tape, 

1.4.3.2 Writing a Tape 
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to tape is indicated in a command line by an 
(3) preceding the list of files or UIDs to be 
pe . Tape positioning commands may precede the 
these will be performed before writing the 
D specification must be enclosed in square 
] f ). A file specification may include its UID 
rackets), otherwise the last UID appearing in 
cification (in the same or a previous command 
sumed. Multiple file or UID specifications in 
ne must be separated by commas. 



Tape positioning commands may be interspersed in the 
list of file or UID specifications and will be performed 
in tne order encountered. When a tape positioning 
directive follows a file or UID specification, the slash 
may serve as the delimiter, so that the comma following 
tne file or UID specification may be omitted. 

Examples: 



•MT:/APs[300302] ' 



Writes the UFD dump for 300302 at the 
end c'f existing data on the tape. 



'MT: =[001001 ]HEP0S,C0HTR0L/RW ! - 



Copies the two named files from UID 
001001 to tape, then rewinds tne tape. 
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1.4.3.3 Reading a Tape 

Reading from tape is indicated by an equal 
sign ('*') as the last character in the command line. 
Preceding the equal sign is a list of one or mere file or 
UID specifications, separated by commas. A UID 
specification must be enclosed in square brackets ('[]'). 
A file specification may include its UID (in square 
brackets), otherwise the last UID appearing in a file 
specification (in the same or previous command line) is 
a ssurned . 

Tape positioning commands may be interspersed in a 
list of file specifications and are performed in the 
order specified. In the case of restoring UFD dumps, the 
specified UIDs are restored in the order in which they 
occur en the tape regardless of their order in the 
command line; tnerefore tape positioning directives are 
not useful except at the end of the UID list. When a tape 
positioning directive follows a file or UID 
specification, the slash may serve as the delimiter, so 
tnat tne comma following the file or UID specification 
may be omitted . 



Examples: 

'MT:/FF,[300302]ABC/FF2,XYZs' - 



Copies the second and fifth files from 
tape into UID 300302. 



' MT: [001001], C 300300], [ 300 302 ] / RW* ' - 



Restores the files for UIDs 001001, 
300300, and 300302, tnen rewinds the 
tape . 
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1.4.3.4 Indirect Command File 

An indirect command file is a text file, each line 
(logical record) of wnich is a command line as described 
in the preceding sections on reading, writing, and 
positioning tapes. The leading f MT:' found in console 
commands is ommitted from commands in an indirect command 
file. Tne Tape Manager is directed to process the 
commands in a command file by a message from the 
operator's console of the form: 

»MT:@[UID]file name' . 

The * Tape Manager then opens the specified file and 
reads and performs each command until end of file is 
reached. A command file may contain any legal Tape 
Manager command except '§...'; that is, indirect command 
files may not be nested. 

1.4.3.5 Terminating Command Processing 



Wnen the' 
command line 



Tape Manager is finished processing a 
or an indirect command file, the message 



'MT:' is displayed on the operator's console. If the Tape 
Manager encounters an error while processing a command, 
an error message is displayed on tne operator's console 
and processing of tne command line or indirect command 
file is terminated. 

If it is desirable to prematurely terminate the 
processing of a command line or indirect command file, 
tnis may be accomplished by sending any message to tne 
Tape Manager. Processing of the current command or file 
of commands will halt and the new message will be 
processed as a command. 

1.4.4 Functional Description 



s t n n d a 
n o w e v e 
record 
data 
buffer 
tn a n i p u 
p o i n t 
forcin 
pn y s ic 



n 

rd 
r , 

S ♦ 

i s 



r eco 
cal 
sin 
tne 
a vc 
and 
1 a t i n g 

to tn 
g the 
a 1 read 



rd mode, disk files are read or written with 
Is to tne runtime I/O routines. In dump mode, 
ce tape records are equivalent to physical disk 
overhead of unblocking, reblocking, and moving 
ided by transmitting eacn record between the I/O 
tne tape directly. Tnis is accomplished by 
the disk file variable (in assembly language) to 
e end of the block after each tape transfer, 
next call to tne appropriate I/O routine to do a 
or write of the disk file. 
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1.4.5 Error Messages 
MESSAGE 
Unknown Account - UID - 

Command Error 
Parameter Error 
Illegal Function 
Bad Tape Format 

End of Volume on Tape - 

Tape I/O Error:nnnnnn - 

Tape on Write Lock 

UID Table Overflow 



Bad Di rector y 



Command Aborted 



MEANING 

The UID in a command, is not known to 
the system . 

Command not recognized. 

Invalid parameter in command. 



The tape format does not match the 
command being processed . 

Premature end of volume reached while 
processing a command. 

Bad status after a tape operation; 
nnnn is the status. 

Attempt to write on a tape which has 
no write ring in. 

Tne list of UIDs to be dumped or 
restored is longer than the program 
can accomodate; remaining UIDs will 
not be processed. 

An error was encountered in 
processing a file header. 

Tne current command line or indirect 
command file has been prematurely 
terminated due to error or operator 
intervention. 



Tape Unit Not Ready - Tape unit is off-line. 
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For . R, C, P and D requests, if »<value> is specified, 
the contents of the location specified by <Starting Address> 
are replaced by <Value>. 

For all requests, the processor to be accessed is 
specified by the processor parameter. If this parameter is 
omitted, processor is assumed. 



In the event that the <Filename> parameter is provided, 
tne HEP Debugger will send the input message back to the 
originating task when the operation is complete. This allows 
tne Datcn Monitor to determine when a dump is complete and 
the HEP resources may be freed. 
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1.5 HEP Debugger 

Tne HEP Debugger is used to examine and modify HEP memory 

and examine the PSW queue. It is normally used by the Batch 

Monitor for taking user dumps, but can also be used from the 
operator's console. 

All HEP Debugger functions use the KI task and code in the 
HEP Kernel to obtain HEP related information. Thus the HEP 
Debugger cannot be used if the Kernel or the UNIBUS to switch 
interface is not working. In these cases, program and data memory 
may be examined using the IML maintenance task (MP). 

1.5.1 Command Format 

Tne HEP Debugger responds to single line text commands 
with tne following syntax: 

[<Request Ty pe> ] <St ar ting Address> [ , Ending Address ][. P<Processor> ] 

JjMlFi lename>] / 

y (Brackets denote optional parameters) 

[=<value] \ 

Valid request types are a single alpha digit drawn from: 

R - Register Memory 

C - Constant Memory 

P - Program Memory 

D - Data Memory 

S - Program Status Words 

If <Request Type> is omitted, and the leading character 
of tne starting address is numeric, data memory is assumed. 
If <Eriding Address> is omitted, it defaults to 
<Starting Address>. If the /<Filename>- qualifier and the 
=<value> qualifier are absent, for R, C, P, and D request 
types, all memory locations between <Starting Address> and 
<Ending Address> are displayed. For S request types, 
<Starting Address> is taken as a task number, and all PSW s 
witn tnat task number are displayed. 

If /<Filename> is specified, the requested data is 
written in binary format to the file specified. For S 
requests to a file, all PSW snare dumped. 
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1.7 Editor 

1.7.1 Overview 

The HEP System Editor is a line-oriented text editor 
which operates on sequence numbered word type or on sequenced 
or non-sequenced record type files of text. The Editor also 
performs file utility functions such as listing, copying, 
renaming, or deleting files, listing the user's directory, 
and submitting a file as a job. 

Options . for terminating an edit session include 
canceling tne edit (preserving the original file), saving the 
updated file under a new name (preserving the original file), 
and replacing the original file with the updated file. In the 
latter two cases, the updated file may be saved as a record 
file, witn or without sequence numbers, or as a sequence 
numbered word file. The Editor supports the inclusion of 
lines of text from an auxilliary input file, which may be the 
file being editted. 

A separate Editor task' services each terminal or port in 
tne HEP system; all the Editor tasks share the same program 

code but eacn has its own data space. 

1.7.2 Command s 

Tne Editor is the only task which communicates with 
terminals other than the operator console, therefore messages 
(commands) to a terminal Editor are not prefaced by any task 
identifier. However, the operator console is also serviced by 
an Editor task, and its identifier 'ED: 1 must preface Editor 
messages. Commands to tne Editor fall into tnree categories: 
leg on/off commands, file utility commands, and edit 
commands. Any command which results in substantial output to 
the terminal may be prematurely terminated by typing a 
carriage return. 

In trie following command descriptions the syntax of each 
command is given. Capital letters in command mnemonics 
represent tne minimum portion of the word to be supplied for 
command recognition. 
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1.7.2.1 Log On/Off Commands 

When no user is logged en to an Editor task, that 
task monitors any signal on the line looking for a 
carriage return at various line speeds to determine the 
speed at which the terminal is operating. Tnerefore 
before legging en, it is necessary to type carriage 
return until the system responds with a greeting. 

1 . 7.2. 1 . 1 Log On 

Hello Cuid] 

Tne user wnose identification number appears in 
the backets is logged onto the system. The Editor 
responds by displaying a greeting with the current 
date and time . 

1.7.2.1.2 Log Off 

Bye 

The user is- legged off the system. If an edit 
was in progress, it is aborted. The Editor responds 
by displaying the date and time. 

1.7.2.1.3 Assistance 

A user who is logged on may obtain a display of 
all tne Editor commands and syntax by typing '?'. 

1.7.2.2 File Utility Commands 
1.7.2.2.1 List Directory 

LD 

The name of each file in the lcgged-cn user's 
file directory is displayed, including the logical 
record lengtn,- tne file size in blocks, and the 
creation, last modification, and last access dates. 
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1.7.2.2.2 Copy a File 

CF file specification, file name 

A file, named by the second parameter, is 
allocated in the user's UFD and the contents of the 
file represented by the first parameter (which may 
include a UID) are copied into it. The output file 
must not already exist. 

1.7.2.2.3 Delete a File 

DF file name 

The named file is deleted from the user's UFD 
and the space allocated to the file is freed. 

1.7.2.2.4 List a File 

LF file specification 

Tne contents of the file (which may be in 
another UFD) are listed on the terminal. 

1.7.2.2.5 Rename a File 

RF file name, file name 

The file in the user's UFD named by the first 
parameter is renamed to the second parameter. The 
second file name must not already exist. 

1.7.2.2.6 Submit a Job 

SUbmit file specification 

The Editor builds and sends to the Reader task 
a message containing the UID and file name 
specified, to be submitted as a job stream. If the 
file specification dees not contain a UID, the 
logged on user's UID is used. If the parameter is 
not provided, the updated version of the file being 
editted is submitted. 
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1.7.2.3 Edit Commands 

In the following syntax descriptions, parameters 
appearing in square brackets are optional. The letters N, 
M, L, and I represent numbers. 

1.7.2.3.1 Edit a File 

Edit file name 

The Editor initiates an edit session for the 
specified file. This includes copying the file to a 
word file if it is a record file and assigning 
sequence numbers if it is not sequenced. 

1.7.2.3.2 Copy Lines 

Copy N[-M][/file speci f ication ] , L[ , I ] 

Tne Editor copies line numbers N through M from 
tne specified file, inserting them in the file being 
editted, starting at line number L and incrementing 
by I. If M is omitted, only line N is copied from 
tne file. If tne file specification is omitted, the 
lines are copied (replicated) from the file being 
editted. If I is omitted, the last increment 
specified in any command is used. 

1.7.2.3.3 Move Lines 

Move N[-M],L[ , I] 

Lines N through M are inserted starting with 
line number L, incrementing by I, and the lines are 
deleted from their former position. If M is omitted, 
only line N is moved. If I is omitted, the last 
increment specified in a command is used. 

1.7.2.3.1 Insert a Sequence of Lines 

Sequence L[ , I ] 

Sequence insert mode is established, starting 
witn line number L and incrementing by I. The user 
is prompted for eacn line of text by a display of 
the next line number in sequence. The process is 
terminated by typing a carriage return as tne only 
cnaracter en a line, or by overlapping an existing 
line number in tne file. 
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1.7.2.3.5 Replace a Text String 

Replace /string 1/string 2/[N[-M]] 

The first occurence of string 1 is replaced 
with string 2 in every line in the range. If M is 
omitted, the range is the entire file. Tne slash 
delimiter may be any character. 

1.7.2.3.6 Delete Lines 
Delete N[-M] 

Tne specified line or range of line3 is deleted. 

1.7.2.3.7 Direct Insert 

N text 

Line N is placed in the file, containing the 
text following the line number N. If line N already 
exists, its contents are replaced by the new text. 

1.7.2.3.8 Direct Delete 
N 

Line number N is deleted from the file. 

1.7.2.3.9 Find a Text String 

Find /string/[M[-M]] 

The Editor searches tne specified range of 
lines for occurences of the string and displays on 
the terminal all lines containing the string. The 
slash delimiter may be any character. If M is 
omitted, only line N is searched; if N is also 
omitted, the entire file is searcned. 
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1.7.2.3.10 List Lines 
List [NC-M]] 



All lines in the file in the specified range 
are displayed on the terminal. If M is omitted, only 
line N is displayed; if N is also omitted, the 
entire file is displayed. 

1.7.2.3.11 Renumber the File 

Number N[-M ] , L[ , I] 

The Editor renumbers the specified range of 
lines, assigning new sequence numbers starting with 
L and incrementing by I. If M is omitted, only line 
number N is renumbered. If I is omitted, the last 
increment specified in a command is used. If the 
renumbering of tne range would cause the file to be 
out of sequence (i.e. lines following the range have 
lower numbers, or lines preceding the range have 
higher numbers), then no renumbering is done. 

1.7.2.3.12 Save the Changed File 

SAve [file name ] [ , Rn ] [ /S ] 

or 
SAve [ file name] [ ,W] 
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1.7.2.3.13 End the Edit Session 
Off 



The Editor terminates an edit and closes all 
files. If the edit file has been modified, a save 
command must be performed before the off command is 
accepted . 

1.7.2.3. I 1 * Cancel the Edit 

ABort 

Tne current edit is terminated and the updated 
file is deleted. The original file is retained. 

1.7.3 Functional Description 

The Editor applies updates to a temporary copy of the 
file; the actual file is not affected until the user issues 
tne save command. It is always possible to cancel an edit 
session, leaving tne file as it was before the edit started. 
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When tne user saves an edit, the original file is 
deleted if necessary and the final output file is renamed to 
the desired name, making it a permanent rather than a 
temporary file. 

When a record file is editted, it is initially copied to 
a temporary word file. Line numbers are assigned unless the 
record file contains embedded sequence numbers at the end of 
eacn logical record. Embedded sequence numbers are identified 
by tne high-order bit being on in the first byte of the 
8-byte number. If present, the embedded sequence numbers are 
extracted and used as the line numbers as the file is copied 
to a word file. The sequence numbers in the text are replaced 
by blanks in tne word file. 

1.7.4 Running a Job From the Editor 

Wnen the submit command is used to cause a file which is 
a job stream to- be submitted as a job, the Editor builds and 
sends a command to the Reader task. The Editor uses the 
message buffer for terminal output and builds all fields of 
tne message directly. Tne message text consists of a UID 
(eitner supplied in the submit command or taken from the 
user's log-cn) and a file name. Tne Editor does the trap to 
send tne message, then does a trap to obtain a new message 
buffer. This new message buffer becomes the terminal output 
buffer . 

Wnen a job submitted by an Editor has completed 
execution, a completion message is received by the same 
Editor from the Batch Monitor task. Informative messages of 
tnis sort are distinguished from user commands by tne 
presence of a backslash (line cancel character) as the first 
character of the message. These messages are 3imply displayed 
en tne terminal. 
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1 . 8 Batch Monitor 

1.8.1 Overview 

The Batch Monitor runs as a task under the Executive. It 
is responsible for job scheduling, resource management, and 
processing status changes for jobs in execution. The Batch 
Monitor receives job descriptor messages from the Reader task 
and maintains a queue of jobs to be run. As resources are 
available, the Batch Monitor removes jobs from the queue and 
initiates execution; a queue of jobs in execution is also 
maintained. At job step termination, the Batch Monitor 
initiates the dump function if requested. The Batch Monitor 
sends completed jobs to the Writer task for printing. 
Operator commands are available to examine the queues, 
re-order the job queue, suspend or cancel jobs, and change 
HEP partition sizes. The operator can also instruct the Batch 
Monitor to quiesce the system by shutting down the Reader 
task and not starting any new jobs. 

1.3.2 Commands 

The Batch Monitor is accessible only from the operator's 
console, directed by commands in the form of messages 
prefaced by 'BM:' (the task ID for the Batch Monitor). There 
are two categories of commands: job-related and 

system-related . 

In the following command descriptions the syntax of each 

command is given. Capital letters in command mnemonics 

represent the minimum portion of the word to be supplied for 
command recognition. 

1.8.2.1 Job-Related Commands 

In the following syntax descriptions 'nnnn' 
represents a four-digit system-assigned job number which 
uniquely identifies the job. 

1.8.2.1.1 Move Job to Top of Queue 

Next nnnn 

Job number nnnn is moved to the top of the 
job queue so that it will be the next job 
started . 



58 



HEP OPERATING SYSTEM 

1.8.2.1.2 Suspend Job Execution 

SU.spend nnnn 

If job number nnnn is in execution, the 
Batch Monitor sends a suspend message to each 
task in the job which is currently, active. 

1.8.2.1.3 Resume Job Execution 

Resume nnnn 

If job number .nnnn is in execution, the 
Batch Monitor sends a resume message to each 
task which is currently paused. 

1 .8.2. 1 .'I Cancel a Job 

CAncel nnnn 

If job nnnn is in execution, the Batch 
Monitor sends a cancel message to each task in 
the job. If job nnnn is in the job queue, it is 
removed so that it will not be executed. 

1.8.2.2 System-Related Commands 

1.S.2.2.1 Set HEP Partition Sizes 

Partition p ,m , s1 , s2 , s3 . . . 

The Batch Monitor sends a message to the 
Kernel in PEM number p requesting that memory 
type m be partitioned according to the sizes 
s1, s2, etc. The number of sizes specified must 
be less than or equal to the maximum number of 
partitions allowed in the memory type. The sum 
of all the sizes must be less than or equal to 
the physical amount of the specified memory on 
the specified PEM. Partitions may be 
reconfigured while jobs are running as long as 
the boundaries of the active partitions are not 
affected. If the requested partitioning cannot 
be performed because of violation of any of the 
above criteria, the partitions message is 
modified to reflect the actual current 
partition sizes. In any case, the message is 
returned to fr* Batch Monitor and is then 
displayed in tabular format. 
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If the operator simply wants to know what 
the current partition sizes are, an easy method 
is to type a set partitions command with a 
single size field which is larger than the 
total amount of memory of that type. 

1.8.2.2.2 Set Control Card Processor 

CC [uid]file name 

The Control Card Processor is always 
loaded from a file. If the user wishes to 
specify some file other than the system default 
(i.e. to try out a new Control Card Processor 
program) , this command must be used to direct 
the Batch Monitor to use the desired file for 
loading the Control Card Processor task. The 
named file remains the Control Card Processor 
file until the Batch Monitor receives another 
CC command. 

1.8.2.2.3 Display the Job Queue 

Display Queue 

The Batch Monitor lists on the operator's 
console all jobs waiting to be run, showing the 
job number, name, memory requirements, and 
process count requirements. 

1.8.2.2.4 Display the Jobs in Execution 

Display Active 

The Batch Monitor lists on the operator's 
console all jobs in execution, showing the job 
number, name, data memory partition number,- and 
the PEM number, task number, partition numbers, 
process count, and task status for each task in 
the job. Task status can be 'L* for loading, 
'A' for active (running), 'P' for paused, or 
'D 1 for dormant (no code in this task). 
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1.8.2.2.5 Quiesce the System 

STOp 

The Batch Monitor does not start any more 
jobs from the job queue, and sends a message to 
the Rsader to stop reading job streams. Other 
Batch Monitor activities proceed normally. 

1.3.2.2.6 Resume Normal System Operation 

STArt 

This command is the reverse of STOP; the 
Batch Monitor sends a message to the Reader to 
continue reading jobs, and the Batch Monitor 
resumes initiation of jobs from the job queue. * 

1.8.3 Inter-task Messages 

In addition to commands from the operator's console, the 
Batch Monitor receives (and sends) other types of messages. 
These messages support three basic Batch Monitor activities: 

sending and receiving HEP messages, sending and receiving 
jobs, and taking dumps of jobs. 

1 .8.3. 1 HEP Messages 

When the HEP sends a status change message on behalf 
of some job, the Batch Monitor receives a "switch 
message" from the interface task. A switch message 
consists of one HEP word of data, followed by 32 bits of 
control information. In this case, the HEP word contains 
the data memory address of the HEP message header. The 
Batch Monitor then reads the HEP message header via the 
low speed bus, sets good status in the header, and writes 
the header back to data memory via the low speed bus. The 
second word of the HEP message header contains the length 
and start address of the message data, if any. If there 
is data, the Batch Monitor reads it via the low speed 
bus, then releases the original switch message by sending 
it back to the interface task as a reply. 

The Batch Monitor then processes the HEP message 
according to its type. The types of messages that might 
be received from the HEP are pause, normal termination, 
abnormal termination, and system error. The message 
header contains, in addition to message type, the PEM 
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number and task number from which it came. Except in the 
case of a system error message, the PEM and task number 
are used to identify the job associated with the message, 
by searching the execution queue. Since HEP messages come 
from the supervisor task, 8 is subtracted from the header 
task number to get the corresponding user task number. If 
there is any message data it is displayed on the operator 
console and written to the job's log. file. If the message 
was a normal or abnormal termination, the Batch Monitor 
sends a cancel to any other tasks in the job to force 
them to terminate. 



In 


the case 


of 


Monitor 


displays 


the 


console 


and halts. 





a system error message, the Batch 
message data on the operators 



When the Batch Monitor wants to send a message to 
the HEP, it must first seize control of the interface. 
This is done by sending a a switch message to the 
appropriate interface task (KI) with the target PEM 
number in the first 16 bits of the data word. The 
interface task replies with the data memory address of 
the interface area in the switch message data word. The 
third and fourth words of the interface area are where 
HEP-bound message headers are written. The Batch Monitor 
writes its message header into this area and sends an 
activate type switch message. 
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SUMMARY OF BATCH MONITOR CONSOLE COMMANDS 

Job Related Commands 

Next nnnn - Move job number nnnn to top of job queue. 

SUspend nnnn - If nnnn is in execution, suspend all tasks in 

the job. 

REsume nnnn - If nnnn is suspended, resume execution of its 

tasks. 

CAncel nnnn - IF nnnn is in execution, cancel all of its 

tasks . 

System Related Commands 

Partition p,m , S1 , S2 , S3. . .S7 - 

Set partitions in processor p, memory type m 
to the values in S1...S7. 

CC[uid]Filename - Set the name of the CONTROL CARD PROCESSOR 

load module equal to [uid] filename. 

Display Queue - Display the contents of the Job Queue (jobs 

waiting to be run) . 

Display Active - Display the status of all active jobs. 

3T0p - Do not process any more new jobs. 

STArt - Reverse of STOP, allow Batch Monitor and 

Reader to continue processing new jobs. 

Other Console Commands 

RD: [uid]Filename - Read the jobfile specified and submit it for 

execution . 

PR : [uid]Filename - Enter the file specified in the print queue. 

PR:CAncel nnnn - Remove job nnnn from the print queue. 

PR:CAneel - Stop printing only of file currently being 

printed . 

PR:COntinue • - Resume printing (after printer has gone 

off-line for some reason). 
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HEP DEBUGGER - HD: 

Examine/Modify Memory - 

[<Memtype>]<Start Addr . >[ , Endaddr . ] [ , Pn] [/<Filename> ] 

[=Value] 

Memtype = R, C, P, D or S - Default = D 

Pn = Processor Number - Default = PO 

/<Filename> = Optional Output to <Filename> 

'= Value 1 = Modify Word to Value Specified 

TAPE MANAGER - MT: 

/RW - Rewind tape. 

/AP - Append. 

/FFn - Forward file, n file marks . 'n' default = 1. 

= <[uid ]Filename> - Write < [uid]Filename> to tape. 

Default [uid] = last Cuid] encountered or 
[001001 ]. 

< [uid ] Fi lename>= - Copy < [ uid]Filename> from tape. 

Default [uid] = last [uid] encountered or 
[001001 ]. 

= [uid] - Write UFD dump for [uid] to tape. 

[uid] = - Copy UFD dump from tape to [uid]. 

Tape Manager directives may appear in any order in a command 

line, except that only one '=' may appear. This must be either at 

the front of the command line (for writing to a tape) or at the 
end of the command line (for reading from a tape). 
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EDITOR - ED: 

Editor commands related to file manipulation and batch 
processing of jobs. Operator must be logged on to the Editor. 

BYE - Log off the Editor. 

CF F1,F2 - Copy file F1 to file F2. 

DF F1 ,<F2, . . .Fn> - Delete files specified. More than one file 

may be named on a command line. 

HEL N1 - Log on the Editor with usercode N1. 

LD - List file directory for your usercode. 

LF F1 - List the contents of File F1 . 

RF F1,F2 . - Change the name of File F1 to F2. 

SlJbmit F1 - Submit the (Control Card) File F1 as a job. 

? - Print complete summary of Editor commands. 
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NOTE: Cut out this '15' and tape it as a subscript on page 2 
under HEP DEBUGGER section, the line Mt = Value' = Modify word 
to value xx specified" where the xx's are. 



ALSO, draw a bracket on the left hand side between ,Pn] and 
C/<Filename>] in the third line under HEP DEBUGGER and on the 
right hand side after [ /<Filename> ] . 
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1.11 Disk Builder 

The Disk Builder is a utility task used to initialize and 
reconfigure the disk file system. Tt Is not normally part of an 
operational system system, but is always part of the bootable 
system on a distribution tape. The Disk Builder is unique in that 
it accesses the disk directly, rather than through the File 
Manager. The Disk Builder contains no command error checking of 
any description, and errors or misuse of its commands may destroy 
the file system. The File Manager in a system must be shut down 
while the Disk Builder is used. Disk Builder commands are 
described below. All commands are single letters. 

1.11.1 Format Disk 

The F command causes the disk to be formatted and 
verified. Sectors with read errors are flagged. 

1.11.2 Initialize Disk 

The I command causes, the disk allocation bitmap, the 

master file directory and the user file directory for user 

000 000 000 000 to be built. This readies the disk for use by 
the File Manager 

1.11.3 Create User File Directory 

The U command prompts for a user ID, and creates a UFD 
for this user. Mo check is made for duplicate UFD's. 

1.11.4 Logon 

The L command prompts for a user ID, and uses that ID 
for all subsequent file references. 

1.11.5 Build Bootstrap Sectors 

The B command builds the bootstrap sectors (cylinder 0, 
track 0, sectors and 1). Sector contains a hardware 
bootstrap for ths ROOT, while sector 1 contains pointers to 
the MFD, the bitmap and the disk addresses and boot 
parameters for the separately compiled Executive tasks. 
Sector 1 is used by Root initialization to load the Executive 
tasks. The B command obtains the Sector bootstrap from the 
file "HWBOOT.TSK" in the current user ID. The command prompts 
for a series of task ID's and boot parameters. For each task, 
the following boot parameters must be supplied: 
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Filename - The name of an existing file in the current 
UFD or " taskid, where taskid is a previously 
defined task. If " taskid is entered, the 
bootstrap entry is flagged so that the code 
for taskid will be shared with this task and 
not loaded again. 

Debug Mode - If debug mode is Y, the initial flags of the 
task will offset so that the task will not 
automatically start when the system is 
booted . 

If the - bootstrap sector already contains boot 
information, the user is prompted for each existing entry to 
determine whether to change that entry. After all existing 
entries are processed, new entries may be added. Note that 
since the boot sectors contain absolute disk addresses rather 
than file names, it is necessary to rebuild the boot sectors 
whenever an Executive task or the Root is changed. 

1.11.6 Set Date 

The D command prints the current date (MM/DD/YY) from 
the calendar clock and accepts a new date. Typing an invalid 
date will hang the task and require a reload. 

1.11.7 Set Time 

The T command displays the current time from the 

calendar clock (HHMM:SS) and accepts a new time (HHMM) . If an 

invalid time is is entered, the task will hang and the system 
must be reloaded. 

1.11.8 Make Distribution Tape 

The M command will write a magnetic tape consisting of 
the tape bootstrap contained in the file "MTBOOT. TSK" , 
followed by a core image of the current incore system. This 
tape may be hardware booted. For the tape to be useful, the 
system must be inactive while the tape is being made, and the 
File Manager must be shut down. 

1.11.9 Read Absolute Sector 

The R command allows the operator to read disk sectors. 
The command prompts for the cylinder head, and sector to be 
road. After the sector is read, the command prompts for an 
output mode, starting data v/ord and word count to print. 
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Legal modes are A (ASCII), D (Decimal), H (Hexadecimal) and 
(Octal) . 

1.11.10 Set Indirect File 

The Q command prompts for a file name and obtains 
subsequent commands from that file until EOF or error. 

1.11.11 Shut Down 

The Z command writes out the current bitmap in 
preparation for activation of the File Manager. 

1.11.12 Disk Build Procedure 

This section describes the sequence of operations required to 
build a disk from the distribution tape. 

a) Boot the distribution system from tape; 

b) Set the date and time; 

c) Format the disk (if required); 

d) Initialize the disk; 

e) Define required UFD's, including 001001; 

f) Using the Executive Debugger, set the flags of the 
task FM and MT to zero, allowing them to run; 

g) Using the Tape Manager, copy the contents of UFD 
001001 from the distribution tape; 

h) Shut down the File Manager; 

P Logon as 001 001 ; 

j) Use the Boot command to initialize the bootstrap 
sectors ; 

!<) Shut down the Disk Builder; 

1) Halt and reboot the system from disk. 
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1.11. 1 Format Disk 



Tne F command causes the disk to be 
verified. Sectors with read errors are flagged. 



formatted and 



1.11.2 Initialize Disk 



Tne I command causes. 
master file directory and 
000 000 000 000 to be built. 

tne File Manager 



the disk allocation bitmap, the 
the user file directory for user 
Tnis readies the disk for use by 



1.11.3 Create User File Directory 



for 



Trie U command prompts for a user ID, and creates a UFD 
tnis user. No check is made for duplicate UFD's. 



1 . 1 1 . *J Lo gon 



Tne L command prompts for a user 
for all subsequent file references. 



ID, and uses that ID 



1.11.5 Build Bootstrap Sectors 



Tne B command builds tne bootstrap sectors (cylinder 0, 
track 0, sectors and 1). Sector contains a hardware 
bootstrap for the ROOT, while sector 1 contains pointers to 
tne MFD, the bitmap and the disk addresses and boot 
parameters for the separately compiled Executive tasks. 
Sector 1 is used by Root initialization to load tne Executive 
tasks. The B command obtains the Sector bootstrap from the 
file "HWBOOT.TSK" in tne current user ID. Tne command prompts 
for a series of task ID's and boot parameters. For eacn task, 
tne fo Hewing boot parameters must be supplied: 
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Filename - The name of an existing file in the current 
UFD or * taskid, where taskid is a previously 
defined task. If " taskid is entered, the 
bootstrap entry is flagged so that the code 
for taskid will be shared with this task and 
not load ed again . 



Debug Mode - 



If debug mode is Y , the initial flags of the 
task will offset so that the task will not 
automatically start- wnen the system is 
booted . 



If tne * bootstrap sector already contains boot 
information, the user is prompted for each existing entry to 
determine wn ether to change that entry. After all existing 
entries are processed, new entries may be added. Note that 
since the boot sectors contain absolute disk addresses rather 
than file names, it is necessary to rebuild the boot sectors 
whenever an Executive task or the Root is changed. 

1.11.6 Set Date 

Tne D command prints the current date (MM/DD/YY) from 
tne calendar clock and accepts a new date. Typing an invalid 
dnte will hang tne task and require a reload. 

1.11.7 Set Time 

Tne T command displays the current time from the 

calendar clock (HHMM:SS) and accepts a new time CHHMM). If an 

invalid time is is entered, tne task will hang and tne system 
must be reloaded. 

1.11.8 Make Distribution Tape 

Tne M command will write a magnetic tape consisting of 
tne tape bootstrap contained in the file "MTBOOT . TSK M , 
followed by a core image of the current ineore system. This 
tape may be hardware booted. For the tape to be useful, tne 
system must be inactive wnile the tape is being made, and the 
File Manager must be snut down. 

1.11.9 Read Absolute Sector 

Tne R command allows the operator to read disk sectors, 
Tne command prompts for tne cylinder nead, and sector to be 
rend. After tne sector is road, tne command prompts for an 
output mode, starting d.ita word and word count to print. 
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Legal modes are A (ASCII), D (Decimal), H (Hexadecimal) and 
(Octal) . 

1.11.10 Set Indirect File 

Tne Q command prompts for a file name and obtains 
subsequent commands from that file until EOF or error. 

1.11.11 Snut Down 

The Z command writes out the current bitmap in 
preparation for activation of the File Manager. 

1.11.12 Disk Build Procedure 

Tnis section describes the sequence of operations required to 
build a disk from the distribution tape. 

a) Boot tne distribution system from tape; 

b) Set the date and time; 

c) Format the disk (if required); 

d ) Initialize the disk; 

e) Define required UFD's, including 001001; 

f) Using the Executive Debugger, set the flags of the 
task FM and MT to zero, allowing them to run; 

g) Using the Tape Manager, copy the contents of UFD 
001001 from the distribution tape; 

n) Shut down tne File Manager; 

i ) Logon as 00 1 001 ; 

j) Use tne Boot command to initialize tne bootstrap 
sectors ; 

k) Snut down tne Disk Builder; 

1 ) Hilt and reboot tne system fr om <\ i s k . 
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2. RESIDENT OPERATING SYSTEM 



Tne HEP computer contains four different types cf memory: 
program, register, constant, and data. Programs executing on the 
machine are allocated a "task" in which to run. Each "task defines a 
contiguous region of each type of memory. The hardware restricts each 
user to his own region of memory, and restricts the type 
may make to eacn memory type. " 
constant memory 



read/write . 



memory 
is read-only; 



Program memory 
and register and 



of access he 
is execute-only; 
data memory are 



A task may contain one or several processes, which are 
executable code sequences. Several processes may be simultaneously 
executing in tne HEP, unlike conventional computers. Processes are 
implemented by a set of nardware registers, of which there is a fixed 
number; tnus an error condition (create fault) exists wnen too many 
processes come into existence in the processor. Since existing 
processes can create new processes at will, processes must be 
allocated to tasks and managed just as memory must be allocated and 
managed. 

All of tne sixteen hardware implemented tasks in the HEP are not 
equivalent. Tasks 0-7 are user tasks. In these tasks, privileged 
instructions are forbidden. In tasks 8-15, privileged instructions 
are allowed. Tnese tasks, called "supervisors", perform system 
services for tne user tasks. User tasks request these services with 
"supervisor call" (SVC) instructions. These instructions generate a 
"trap", creating a process in a supervisor task and suspending 
execution of tne user. The hardware forces user traps to a particular 
supervisor task, for example, task 2 traps to task 10. Tn general, 
task k ( k < 3 ) traps to task k + 8 . 

Supervisors may also generate traps. All traps from a supervisor 
create a process in task 8. A supervisor trap suspends tne supervisor 
in tne same way a user trap suspends the user. Note that a trap 
suspends ALL processes in a task, not just the process causing the 
trap. 



Tne HEP computer is interfaced to I/O devices and tne user via 
tne Executive computer. In hardware, the Executive can read and write 
HEP program and data memory and certain control registers via a low 
speed (actually quite nign speed) bus (LSB) interface. Privileged 
instructions on tne HEP can also manipulate certain of these 
registers. In addition, tne Executive and the Resident Operating 
System are interfaced via tne passive interface, wnich allows 
supervisory processes to internet w i t n tne Executive. One of tne >n a i n 
supervisory functions of tne HEP 0/S is to control tne flow of data 
tnrougn tnese interfaces. 
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2. 1 Kernel 

Tne Kernel of the resident operating system occupies task 8 
in every PEM. The base and limit registers of the Kernel are set 
to allow it to address all of memory. The Kernel is logically 
divided into tnree parts - the Inbound Kernel, which responds to 
directives from the Executive; the Outbound Kernel, which 
responds to traps from Supervisors; and the Create Fault Handler, 
whicn responds to create fault traps. Eacn of these Kernel 
sections is described below. Data structures used by the Kernel 
are described in Section 2. I.I, along with Kernel initialization. 

2.1.1 Kernel Data Structures and Initialization 
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el accesses two types of data structures: 
structure unique to each PEM, and shared data 
ssed by all PEM ' s in a system. The shared data 
located at the base of data memory, and relate 
1 and status of data memory. Tne private data 
How tne shared data structure. During 

each Kernel uses the RCLK instruction to 
n unique processor number. Tnis number is used 

private data structure area into a unique 
a memory. In addition, each processor examines 

snared cell defining tne base of user data 

Kernel sets this cell to tne end of its own 

if tne previous content of the e <* 1 1 is not 

tnan tn-Jt. Thus, after all processors are 
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initialized the cell contains the correct base of user data 
memory, regardless of the order in wnich the processors were 
initial ized . 

2.1.1.1 Memory Management Data Structures 

Memory is managed using a partition table for each 
memory type. The length of each table is an assembly time 
parameter of the Kernel. The partition table for data 
memory is in the shared area, while the tables for 
register, constant and program memory are in the private 
ar ea . 

A partition table consists of a number of partition 
descriptors, followed by a terminator word. The format of 
tne table is shown in Figure 2.1. 



PARTITION 
DESCRIPTORS 



TERMINATOR 
W R D 



USE 



COUNT 



28 



28 



LENGTH 



(WORDS) 



BASE 
ADDRESS 
(WORDS) 



(Preceding word must 
be negative) 









-1 


TOTAL 
LENGTH 


BASE 

OF 

UNUSED 



Figure 2.1 - PARTITION TABLE FORMAT 



Tne base address or length of a partition descriptor 
may only be cnanged wnen its use count is zero. 
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2.1.1.2 Task Management Data Structures 

Tasks are managed with a task table, process table 
and task status words. Since tasks are local to PEMs, 
these structures reside in private areas or in Kernel 
reg i ster s . 

Tne task table is an array of seven task 
descriptors, each corresponding to a user /supervisor task 
pair. Tne format of a task descriptor is given in 
Figure 2.2. 

WORD 



POINTER TO 
PARTITION 


PROGRAM MEMORY 
DESCRIPTOR OR 


POINTER TO 
PARTITION 


REGISTER 
DESCRIPTOR 


MEMORY 
OR 


POINTER TO 
PARTITION 


CONSTANT 
DESCRIPTOR 


MEMORY 
OR 


POINTER TO 
PARTITION 


DATA MEMORY 
DESCRIPTOR OR 






Figure 2.2 - TASK DESCRIPTOR 



Each element of the task descriptor contains the 
byte address of the partition descriptor for the memory 
used by tne task. The use count in the partition 
description is the number of task descriptors, system 
wide, wnieh refer to the partition. For all but data 
memory, tne use count cannot exceed 1. 

Tne process table is an array of seven elements 
followed by a termination word. Each element contains- the 
number of processes allocated by software to the 
corresponding task. The termination word contains the 
maximum total number of processes allowed by software. 



Task status is contained in several registers. Eacn 
register uses one bit per task to record status. Tne 
tnree task states are VALID, ACTIVE and LOADED. A task 
becomes VALID when a program loading is begun in tne 
task, and becomes not VALID when the program terminates 
normally or abnormally. A task becomes ACTIVE wnen it is 
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started (after loading) or resumed (after a pause). The 
task is not ACTIVE during program loading and after a 
pause. A task becomes LOADED upon completion of program 
lead, and becomes not LOADED upon normal or abnormal 
termination. These states affect the type of directive 
w'nicn tne Kernel will accept for tasks. 

2.1.1.3 Communications Data Structure 

Communications between tne Executive and the Kernel 
is accomplished using a pair of message headers located 
in the Kernel private data structures. One message header 
is used . exclusively by the Inbound Kernel for 
communication witn the Executive task KI. Tne other is 
used exclusively by the Outbound Kernel for communication 
witn tne Executive task KO. A message header is a 
two-word block whose format is given in Figure 3.3. 



8 



8 WORD 



PR 00. 



NUMBER 



SOURCE/1 
DEST. 
TASK 



STATUS 



EXT 



MESSAGEJMESSAGE 
DATA 



TYPE 



MESSAGE LENGTH 
(Wo rd s) 



MESSAGE ADDRESS 
(Byte Address in 
HEP Data Hemnrvl 



Figure 3.3 - MESSAGE HEADER FORMAT 



For the Inbound Kernel, message length and all the 
fields in word are supplied by KI, after which the 
Kernel fills tne address halfword witn the address of the 
Kernel data buffer, located in the pivate data area. If 
tne message is invalid, the status field is set to a 
non-zero value and the buffer address is not supplied-. It 
is tnen tne responsibility of the Executive to not 
transmit any data. Tne destination of all outbound 
messages is the Kernel (task 8). 

For the Outbound Kernel, all fields are supplied by 
tne Kernel. The data length and message address are 
obtained from the supervisor wnich trapped to request the 
message be sent. The message address is relocated by the 
Kernel to an absolute data memory address. Since no 
recovery is possible, tne status field is not enecked by 
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tne OUTBOUND Kernel. The source task field is the task 
number of the user task (1-7) whose supervisor trapped. 

2.1.1.4 Initialization 

Wnen the Resident Operating System, is first loaded, 
Executive causes an IPL trap which begins execution 



the 

of 

tne 



the Kernel initialization code. This code identifies 
processor number and sets up the private data 
structures. Partition, task and process tables are 
initialized to the inactive and unassigned states. All 
ked not VALID, not ACTIVE and not LOADED. 



tasks are mar 



Initialization communicates with the Executive by 
sending the base address of the private data area, wnich 
is also the Executive communications area, to tne first 
Unibus-to-Switch Interface location with a STO 
instruction. This address is received by the Executive KI 
task and is maintained by that task for the duration of 
system operation. After the Executive handshake, the 
initialization code branches to the directive reception 
cede of the inbound Kernel . 

2.1.2. Inbound Kernel 

Tne Inbound Kernel processes directives received from 
tne Executive KI task. These directives originate with either 
tne Executive Batch Monitor or the HEP Debugger. The Inbound 
Kernel is a single process in task 8 which normally waits in 
tne Unibus-to-Switch interface for the result of a memory 
read instruction. When a directive is to be processed, the 
Executive KI task provides eitner a "0" or a " 1 " as the 
result of the read. This relinks the Inbound Kernel in the 
PEM process queue and execution begins (resumes). 



Trie message type in the inbound message neader is 
cnecked for reasonabil i ty and tne destination task is checked 
to verify that it is task 8. If these conditions are met,- the 
data value returned by tne Executive is used to enter phase 1 
or pnase 2 directive processing. 

If tne data value was 0, phase 1 processing is entered. 
During pnase 1, tne specific message code is validity 
cnecked, tne message length is checked and message specific 
c nee king is performed on the neader. If pnase 1 is successful 
tne message status is zeroed, tne Kernel buffer address is 
supplied and tne re;id to tne Unibus-to-Switcn interface is 
reissued . 
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When the read is again satisfied, the data value is 
again checked. If tne value is not zero, phase 2 processing 
i3 entered. Pnase 2 processing rec hecks the message type and 
status. If satisfactory, the contents of the Kernel buffer 
are used for message specific processing, and may be altered 
to display results. After Phase 2 processing is complete, the 
read against the Unibus-to-Switch interface is reissued to 
await a new directive. 



A total of 13 directives, some with 
accepted. Tnese are briefly described below. 

2.1.2.1 Examine Directive - Type 21 (16) 



var ient s , are 



Examine Directive causes the Kernel to read the 

of a single word of memory and place its value 

Kernel buffer. The message data extension in the 



The 
contents 
in tne 
header specifies the memory type, as shown in Table 2.4 

VALUE MEMORY TYPE 



PROGRAM 
REGISTER 
CONSTANT 
DATA 



Table 2.4 - MEMORY TYPE CODES IN DIRECTIVES 

Tne first word of tne Kernel buffer contains the 
address to be examined. Upon completion, the next word 
will contain tne register descriptor or 0, and the 
following word will contain the value. 

2.1.2.2 Modify Directive - Type 1 (16) 

Tne Modify Directive causes the Kernel to replace 
tne contents of a single word of memory with a new value. 
Tne format of the directive is the same as tne examine 
directive, except that all fields are supplied by the 
Executive . 

2.1.2.3 Cancel Directive - Type 2 (16) 



Tne 
(1-7) in 



Cancel Directive specifies a user task number 
v.-,/ * , , tne message data extension. Tnis task must be 
VALID. Tne message causes tne Kernel to create a process 
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in the task with an all-ones PC and UTM. When the task 
next becomes active, tne process will trap to its 
supervisor, which will recognize the unusual PSW and 
terminate the task. 

2.\,Z.^ Suspend Directive - Type 3 (16) 

Tne Suspend Directive specifies a user task number 
in the message data extension. The task must be VALID and 
ACTIVE. The message causes the Kernel to create a process 
in tne task with a PC of and an all-ones UTM. When this 
process traps to its supervisor, the supervisor will 
leave the ' task dormant and send a PAUSE message through 
tne Kernel. This will mark the task not ACTIVE. 

2.1.2.5 Resume Directive - Type k (16) 

Tne Resume Directive specifies a user task number in 
tne message data extension. If the data length of the 
message is non-zero, the message data is placed in the 
data memory of the task starting at user location 0. The 
task is then activated. Resume requires that the task be 
VALID and not ACTIVE. Tne task is set ACTIVE by Resume. 

2.1.2.6 Load Directive - Type 5 (16) and Type 7 (16) 
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For all load directives, runtime constants are 
initialized in tne supervisor space of the user task, tne 
task is marked VALID and not ACTIVE, PSW's having the 
tasks' task number are erased from the hardware PSW 
queue, and tne loader process is created in tne 
appropriate supervisor. 
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2.1.2.7 Miscellaneous Examine Directive - Type 22 (16) 

Tne miscellaneous examine directive copies various 
information into the Kernel data buffer. The message data 
extension specifies what data to copy; as shown on the 
next page. 



MDE 
VALUE 



ACTION 



Read PSW queue into buffer. 

1 Read all TSW's into buffer. 

2 Read CFU control into buffer. 

3 Read ECC register and clock into buffer. 



Read partition descriptors and process count 
for all tasks into buffer, in order by task, 
and memory type, 5 words per task. 



2.1.2.3 Set Partitions" Directive - Type 23 (16) 
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At tne conclusion of tne directive, tne then current 
partition table (previous or updated) is copied to the 
Kernel buffer for possible examination by the Executive. 
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2.1.2.9 Set Task Directive - Type 2H (16) 
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If tne reassignment was successful, the first word 
of the Kernel buffer is set to zero, otherwise it is set 
to - I . 

2.1.2.10 Create Process Directive - Type 6 (16) 

Tne Create Process Directive unconditionally creates 
tne process whose PSW is in the first word of the Kernel 

buffer . 



2.1.2.11 Dump Directive - Type 25 (16) 

Tne Dump Directive is identical to the Examine 
Directive, except tnat tne Kernel buffer is filled with 
63 register descriptor /value pairs starting at the 
address contained in the first word cf the Kernel buffer. 
Tn^ data begins at the second word of tne buffer, and the 
last word of the buffer is not used. 

2.\.2..\Z Set Process Directive - Type 26 (16) 

Tne fv* t Process Directive specifies the new contents 
of tne process table. Tne new process counts are summed, 
and if tne sum does not exceed the software process count 
limit, tne process table 
buffer. If tne limit 
Kernel buffer 
Changed . 



s copied from the Kernel 
_ s exceed ed , the f ir st word cf the 
is set to -1 and the process table is not 
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2.1.3 Outbound Kernel 

Outbound Kernel processes are produced by error and SVC 
traps from supervisors. While multiple outbound processes may 
exist simultaneously only one such process per PEM makes 
progress at a given time, since all Outbound Kernel processes 
interlock on a single Kernel regi ster . Thi s requirement is 
imposed because Outbound Kernel code is not re-entrant. 

2.1.3.1 SVC Processing 

Normal entries into the Outbound Kernel are produced 
by SVC calls from supervisors. Four such SVC ' s are 
recognized' as snown in Table 2.5. 



SVC 



NAME 



MESSAGE 
CODE -HEX 



ACTION 



STOP 



C2 Task set not VALID, not 
LOADED, not ACTIVE 



1 


PAUSE 




C6 


2 


CROAK 




C3 


3 


LOAD 


COMPLETE 


C2 



Task set not ACTIVE 

Task set not VALID, not 
LOADED, not ACTIVE 

Task set LOADED, net 
ACTIVE 



Table 2.5 - Kernel SVC Codes 



For all SVC entries, the data parameter descriptor; 
contained in the register is relocated to an absolute 
memory address and is placed in the second word of the 
outbound message header. Tne first word of the outbound 
message header is set to the message type indicated in 
Table 2.5, and the source task is set to the user task 
number of tne requesting task. Tne processor number is 
placed in tne processor field. 

Tne Executive is notified by storing tne address of 
tne Kernel private data structures into the second 
Unibus-to-Swi ten interface location. Tnis produces an 
interrupt nan died by tne Executive KO task and results in 
tne Baton Monitor reading tne message nender and data. 
After- tne Executive nas read tne data, tne store is 
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responded to, and tne Outbound Kernel resumes execution, 
unlocks the synchronization register and quits. 

As part of all SVZ preamble processing, tne trapping 
process is vectored to a quit instruction and the task is 
reactivated. Thus tne supervisor issuing the SVC 
continues with other processing in progress, but the 
process issuing SVC does not continue after the SVC. 

2.1.3.2 Error Processing 

Normal system operation does not generate error 
traps from tne supervisors. If any occur, or if an 
illegal SVC is issued by a supervisor, it is a fatal 
system error. The trapping PSW, the Kernel PSW of the 
trap handling process, and the instruction causing the 
trap are captured and stored in a fixed 3-word buffer in 
the Kernel. A type C7 message is generated by the Kernel, 
pointing to the 3 word buffer. Tne trapping supervisor is 
left dormant. Occurence of this error will probably 
result in corruption of open disk files and should be 
followed by an immediate system shutdown and reload. 



2. 1 . H 



reate Fault Handler 



If the total number of processes in all supervisor or 
all user tasks exceeds a hardware limit, a create fault trap 
occurs. All user or supervisor processes are placed in a 
qua si -dormant state. The create fault process determines if 
tne fault was a supervisor or user overflow. If the fault was 
a supervisor overflow, the create fault condition is reset 
and operation continues. Tnis should not occur, and is a 
potentially fatal system error. However, since supervisor 
processes cannot be abnormally terminated without causing 
system damage, tne re is no corrective action possible. 

If the fault was a user overflow, the create fault 
handler examines the PSW queue to count the number of 
processes used by each user task. This count is compared to 
tne limit specified in the process table. For all tasks whose 
actual process count exceeds the limit, all such processes 
are vectored to a quit. After these processes terminate, a 
process witn.a cancel PSW is created in tne offending tasks. 
Tne create fault condition is cleared and normal processing 
resumes . 
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2.2 Load er 
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gram leader's function is to read a disk file 
he load module for an executable program and place 

of the load module into program, register, constant 
ory. The loader runs as a supervisor task (9-15). As 
ervisor cede, the leader's constant and program base 
owing code and constants to be shared by all 
Register and data base and limit restrict the loader 
r % y allocated for the task to be loaded. The first 
and 64 data memory words are reserved for the loader 
visor, as is the memory left above a loaded program. 

initialization for a load, certain leader registers 
th control values for the load. In addition, certain 
mory locations within the supervisor task space are 
d . 



2.2.1 Initialization 



Upon startup, the loader determines if this is a "system 
load" or a "user load". For. a system load, the loader takes a 
filename passed in the base of its data memory as the name of 
tne file to load. It issues an open request to the Executive 
File Manager using the tnird Un ibus-to-Swi ten location. This 
file is opened as logical unit 0, using standard I/O 
supervisor protocol. If the' load is a "user load" logical 
unit is presumed already open. 

Witn logical unit open, the loader begins to process 
lead module records. Tnis process continues until the end of 
file, the end of module record is encountered, or the 
relative task number field in the load module record 
descriptor changes. Wnile processing load module records, 
several record types may be encountered. Processing of each 
type is described below. 

2.2.2 Header and Checksum Records 

Header records and checksum records are ignored. 

2.2.3 Task Record 
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requirement in the task record determines the base of the 
register environment pool. This pool is set up during task 
record processing and is intended to allow 40 registers per 
process. Tne top of the environment pool becomes tne user 
register limit, and the TSW is updated to reflect that fact. 
Remaining registers are formed into a pool of 4 register 
blocks for use in concurrent T/0 processing. These register 
environments are also set up by task processing. The task 
record must precede the start record. 

2.2.H Start Record 

Tne start record contains a PC value at which to begin 
execution. Start record processing combines this PC into a 
PS'// witn the register index of the first register 
environment. The resultant PSW is created, however since the 
user task is dormant, execution does not start until the 
Kernel subsequently activates the task. 



2.2.5 Data Record 
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2.2.6 Loader Termination 

Tne loader terminates upon encountering an error, 
encountering a cnange of task or end of module record or upon 

reacning EOF. 

If the loader encounters a change of task, tne load file 
is left open and positioned to the first record of the new 
task. Tne loader terminates with a return code of in the 
data block passed to tne Kernel via SVC3. Key supervisor 
Locks are reset to allow normal operation of tne I/O 
s u p e r v i s o r . 
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In all other cases, the file is closed, and a non-zero 
eturn code is supplied. Table 2.6 describes these codes. 



CODE 
X' 10' 
X'20' 
X'30' 
X 1 40' 
X f 1 1 • 
X'M2' 
X' i4 3 » 



MEANING 

I/O error, reading past EOF or file not found 

Unrecognized record type. 

End of module record reached. 

'Program memory overflow. 

Register memory overflow. 

Constant memory overflow. 

Data memory overf l-o w. 



Table 2.6 - LOADER ERROR CODES 
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2.3 I/O Services 

User I/O requests are handled by the corresponding 
supervisor process via SVC calls. When a user process executes an 
SVC instruction the task is made dormant, and a supervisor 
process is activated. In general, the supervisor will reactivate 
the user immediately after validating and copying the user's 
parameter block. This allows all of the processes in that task to 
proceed except for the process which actually issued the SVC 
instruction. When the supervisor has finished processing the SVC 
it will re-create the user process at the instruction location 
following the SVC, and it will proceed from that point. The 
exceptions to this are SVC 7 (Stop SVC) and 3 (Pause SVC), which 
are not reactivated. In the case of Stop the task will not be 
activated until after a KILL instruction has been issued by the 
Supervisor, and in the case of Pause, the activate will be issued 
by the Kernel when, and if the operator sends a Resume message 
from the system console. 

2.3.1 SVC's 

The services which the I/O Supervisor can perform for 
the user are the following: 

SVC - OPENLU - Allocate and open a disk file at a 
specified logical unit. 

SVC 1 - CLOSELU - Close, rename or delete a disk file on 
a specified logical unit. 

SVC 2 - BUFFERIN - Read a record. 

SVC 3 - BUFFEROUT - Write a record. 

SVC i\ - BACKSPACE - Backspace one record. 

SVC 5 - REWIND - Reposition a disk file to the first 
record . 

SVC 6 - ENDFILE - Write END OF FILE, close a file. 

SVC 7 - STOP - Cancel the user task and print a message 
on the system console. 

SVC 8 - PAUSE - Suspend the user task, and print a 
message on the system console. 
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SVC 9 - INQUIRE - Inquire regarding the OPEN/CLOSE status 
of an LU . If open, return the record length and 
options word. 

*SVC 10 - GETENV - Acquire a supervisor LU buffer. *May be 
executed by CONTROL CARD PROCESSOR only. 

SVC 11 - LOGON - Logon to FILE MANAGER using the user ID 
supplied . 

SVC 12 - GETCORE - Returns the address of the first word 
above the user's Data Memory. 

Refer to Figure A (next page) for Parameter Block 

Formats . 



17 



HEP OPERATING SYSTEM 

A - Requested Access Privilege 

B - Public Access Privilege 

C - Owners Access Privilege 

D - History 

E - Disposition 

F - I/O Direction 

G - Buffers 



OPENLU SVC 0/CLOSELU SVC 1 


STATUS LUNO 


RECLEM (WORDS) 


* VOLUME ID 


t FILENAME 


^Xj G F E 


D C B A 



BUFFERIN SVC 2/3UFFER0UT SVC 3 



STATUS 


LUNO 





LENGTH 


(WORDS) 


<T BUFFER START 






BACKSPACE SVC ^/REWIND SVC 5/ENDFILE SVC 6 



STATUS 



LUNO 







STOP SVC 7 /PAUSE SVC 8 



STATUS 







TEXT LENGTH (WORDS) 


T TEXT 










INQUIRE SVC 9 



ST ATUS __] LUNO j RECLEM (R ETURNED) j 

_T '"_' _~ ' "" JL " ___ n t 

i-:.<:.J . XgjJZQ J XbXLDJ^^ 

RECLEM and A-G fields interpreted as with OPEN and CLOSE, 

returned if LU is OPEN. 



GETEMV SVC 10* 











.a . 








*Ex ecu table only by Control. Card Processor. 

LOGON SVC 11 

STATUS P "~ ~ I 



USER ID CODE (1? BYTES) 







GETCORE SVC }?. 




.1 



(USEP^TOP RETURNED) 

"~ ""' 



i%ure A - HEP SVC Parameter Block Formats 



18 



HEP OPERATING SYSTEM 



In the case of all SVC's , the user's indexed register 
number one (R1:I) is assumed to be a pointer to the parameter 
block. If R1 does not point to a valid user Data Memory, 
address the result will be an abnormal termination (ABTERM) 
(see Section 2.4 - ERROR HANDLER for a description of 
ABTERM). Other errors associated with SVC ' s which will result 
in Abnormal Termination are issuing an illegal SVC number, 
and invalid text pointer in a STOP SVC. All other errors will 
be reflected in the status field of the SVC parameter block. 
Normal return status is zero, anything else indicates some 
abnormal condition. 

Traps which result in the creation of a Supervisor 
process can be caused by a user process issuing a supervisor 
call (SVC) or by the detection of an error condition. These 
traps are received by the Kernel, which examines the PSW to 
determine which type of trap it is. It then creates a process 
in the appropriate supervisor task to process the trap. Error 
traps are processed by the User Error Handler, and SVC traps 
are processed by the I/O Supervisor. 

When a supervisor process is created it will have 
control of a set of ten global registers which are shared by 
the Kernel and all supervisors in that task. In order to 
avoid conflicts only one supervisor at a time is allowed 
access to these registers. Mo other supervisor processes will 
be created until these registers have been released, and once 
they have been released a supervisor may not attempt to seize 
them again. 

There also exists a similar job-wide set of common Data 
Memory which is similarly seized and freed by the supervisors 
in each task. 

When the I/O supervisor is awakened it will already have 
control of the global registers. Its first act is to seize 
the global Data Memory for that job. It will not proceed 
until it has successfully acquired this Data Memory. Having 
acquired an operating environment it will then copy the SVC 
parameter block from user space and examine it. After 
verifying that the user has issued a valid SVC and the 
parameter block which is pointed to by the user's indexed 
register one (R'i:I) is correct, the I/O supervisor will 
re-activate the user task, for all but STOP and PAUSE SVC's. 
This allows the user task to proceed with as short an 
interruption as possible. For those SVC's which require I/O 
Buffers the supervisor will then acquire ono , and then will 
acquire a set of temporary local registers. Having acquired a 
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working environment where necessary the supervisor can now 
release the locks on the global Data Memory and registers and 
proceed with the processing of the SVC. From this point on 
the supervisor is completely re-entrant and, with the 
exception of multiple concurrent I/O to the same logical 
unit, can operate completely in parallel with any number of 
I/O supervisor processes, in any number of tasks. The local 
register environment consists of a set oT four registers 
obtained from a pool. The Data Memory environment (LU 
environment) is 96 words in length. Figure B is a diagram of 
an LU environment. 

OPENLU - SVC 

OPEN SVC acquires an LU environment. If no buffer is 
available it will return an error status to the user. An 
LU environment is made available by the issuing of a 
GETEMV SVC (SVC 10) by the Control Card Processor. Once 
an LU environment is seized its location is recorded in 
the LUTABLE, a job-wide table of open LU's. Entries in 
this table indicate that the LU in question is either 
1) not open, 2) in use, or 3) available for use. The 
LUTABLE entry is marked in use. OPEN LU builds an open 
message from the information in the SVC parameter block, 
which it sends to the file manager. If the open is 
unsuccessful th3 LU environment is returned, the LUTABLE 
entry marked not open, and an error status is returned to 
the user. If the open succeeds, OPENLU will check the I/O 
direction field of the options word. If the direction 
specified is forward, the first record of the file will 
be read. If append is specified the last record will be 
read from the file and the position pointer set to the 
end of the last logical record. Even if a file is empty 
(i.e. contains no records as yet) there will always be 
one physical record in it, and the end of file pointer 
will point to the beginning of that record. 

The contents of the options word will be saved in 
the LU environment to be referred to by successive I/O 
requests. The LUTABLE entry will be marked available, and 
the user process will be created at one past the PC of 
the SVC instruction. If at any time during the processing 
of this SVC an error condition is detected, the LU 
environment will be returned, the LUTABLE marked 
unopened, and an error status returned to the user. 
Figure C shows the format of the open message to the file 
manager. 
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Word 
1 
2 
3 
4 




Word 5'4 
65 
66 
67 
63 
69 



Word 95 



63 



FILE SYSTEM 

message; he ad er 



RECORD 

HEADER 



DATA BUFFER 



62 WORDS IN LENGTH 



COPY OF 
SVC PARAMETER BLOCK 



TO PARAMETER BLOCK IN USER DATA MEMORY 
USER PSW 



I/O SUPERVISOR 
TEMPORARY STORAGE 




27 WORDS IN LENGTH 



Figure B - HEP I/O SUPERVISOR LU ENVIRONMENT 



FILE MANAGER MSGCODE = 



LOGON 

OPEN 

CLOSE 

READ 

WRITE 

OBTAIN 
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Word 





1 

2 
-> 
.5 

4 
5 
6 
7 
8 
9 
10 



MSG 
CODE 



STATUS 



r, 



THIS. 



NEXT ADR 



LEN. FILENAME 




11 



UID 



B 



PREV ADR 



UFD1 



UFD2 



RECSIZE r ACPRIV 



FILENAME (BYTE SWAPPED) 



EOF WORD {FILE LENGTH 




MESSAGE 
HEADER 
RECORD 
HEADER 



.DATA 
BUFFER 



Word 



Figure C - OPEN/CLOSE FILE SYSTEM MESSAGE BLOCK 




MESSAGE 


HEADER 


RECORD 


HEADER 


DATA 


BUFFER 



Figure D - READ/WRITE/OBTAIN FILE SYSTEM MESSAGE BLOCK 



Word 
1 

2 
3 
4 




. CODE 



63 



statu: 



UID (RETURNED) 



USER ID (1? BYTES) 

. 1M» — — — — ■■ W » <■—• • ■— lfcj - ". — M I L?— ■■■■ ■ " ■'■'— i t l WMM I*. I I 




MESSAGE 
HEADER 
RECORD 
HEADER 



Figur- E - LOGON FILE SYSTEM MESSAGE 
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CLOSELU - SVC 1 

CLOSE SVC acquires an LU environment from the 
LUTABLE. If the entry in the LUTA3LE indicates that the 
file is not open error status will be returned to the 
user. After it determines that the LU is open, CLOSE SVC 
will compare the options word which has been saved from 
the open with the options word sent in the CLOSE SVC 
parameter block. Changes indicated will be copied into 
the close message. If the file has been opened with write 
access the current record will be written and the EOF 
pointer will be updated. If the rename bit in the ACCPRIV 
field is on , and a file name is provided, this name will 
be copied- (byte swapped for the PDP-11) into the message 
block. Finally a CLOSE message will be sent to the file 
manager.. The LU environment is then returned and the 
LUTABLE entry marked not open. Status returned by the 
file system is returned in the SVC parameter block. The 
user process is re-created and the local registers are 
returned by the supervisor. Figure C shows the format of 
the close message to the file manager. 

BUFFERIN - SVC 2/BUFFERQUT - SVC 3 

BUFFERIM and BUFFEROUT perform the read and write 
operations respectively to disk files. Except for the 
direction of the I/O they are essentially identical. 
BUFFERIN/OUT acquires an LU environment from the LUTABLE. 
If the LUTABLE indicates the LU is not open an error 
status is returned to the user. EOF condition is checked 
for both operations, and if true, EOF status is returned, 
except where extend and write access has been granted on 
the open of the file. Data is copied to/from the LU 
Buffer and user Data Memory, one word at a time until the 
logical record length specified has been consumed. When a 
logical record crosses the boundary of a physical record 
a physical I/O is performed. In the case of BUFFERIN this 
is just a read. In the case of BUFFEROUT, if the current 
physical record is not the last record of the file the 
current record is written and the next record read into 
the buffer. If the current record is the last record in 
the file an OBTAIN message is sent to the file system 
processor to acquire the address of the next record, and 
have it assigned to this file. This address is copied 
into the next address field of the current record header, 
and the record is written. 
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Upon completion of the I/O the LUTABLE entry is 
marked available, status is placed in the parameter 
block, the user process is recreated, and the supervisor- 
returns the local registers. Figure D shows the format of 
the Read, Write and Obtain messages to the file manager. 

BACKSPACE - SVC 4/REWIND - SVC 5 

BACKSPACE and REWIND each acquire an LU Buffer. As 
with BUFFERIN and BUFFEROUT, if the LUTABLE indicates the 
LU is not open error status is returned. 

BACKSPACE/REWIND must check the current access 
privileges. If write access is included, the current 
record must be written, in case it has been modified. For 
BACKSPACE the current position pointer is decremented by 
the logical record length. If it is decremented beyond 
the beginning of the current logical record, as many 
reads in reverse direction as necessary are performed 
un4:il the position pointer is in the current buffer. 

For REWIND the operation consists of simply reading 
the first record of • the file and setting the position 
pointer at the beginning. 

Error status could be returned if an I/O error were 
to occur of if an attempt is made to BACKSPACE beyond the 
beginning of the file. 

Status is returned in the SVC parameter block. The 
LU Buffer is returned, the LUTABLE entry marked 
available, the user process recreated and the supervisor 
local registers returned. 

ENDFILE - SVC 6 

ENDFILE, in this implementation, has the effect of a 
call to CLOSELU with the default options specified. 

STOP - SVC 7 

STOP does not acquire an LU Buffer, it does not 
obtain a local register environment and the user is not 
immediately re-activated. When the I/O supervisor is 
entered for a STOP SVC the user has already been 
de-activated as a result of issuing the SVC. The 
supervisor verifies the address of the message text in 
the parameter block. It issu2s a KILL followed by an 
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ACTivate instruction against the user task to make 
certain that the user task has no outstanding SFU 
requests. Tt then issues a call to CLOSEALL, which closes 
all open LU's. Finally, the supervisor issues a STOP SVC 
to the Kernel with a pointer to the message passed by the 
User. The STOP SVC to the Kernel is not the same as a 
user STOP SVC, a supervisor STOP request is SVC 0. 

PAUSE - SVC 8 

As with STOP, PAUSE does not acquire an LU Buffer, 
nor a local register environment, and the user is not 
re-activated. The user is already dormant, therefore 
PAUSE simply verifies the address of the text passed by 
the user in the parameter block, and issues a PAUSE SVC 
to the Kernel with a pointer to the same text string. A 
supervisor PAUSE request is SVC 1. 

INQUIRE - SVC 9 

INQUIRE acquires an LU Buffer. If it is found to be 
a new buffer, i.e. the LU in question is not open, the 
supervisor returns a .non-zero status. If the buffer is 
not a new buffer then the LU has already been opened, and 
the supervisor returns zero status, and the record length 
and options word in the parameter block. The purpose of 
INQUIRE is to allow a user to ask the supervisor if an LU 
is open before attempting to do I/O, open or close it. 
The LU could have been opened by the Control Card 
Processor, or by another task within its own job (in a 
multi-PEM environment) . 

GETENV - SVC 10 

A GETENVIRONMENT call is executable only by the 
Control Card Processor. For any other user an illegal SVC 
ABTERM will result. GET ENV does not require a local 
register environment, and does not obtain an LU Buffer. 
The supervisor simply decrements the user's Data Memory 
limit by the length of an LU environment and rewrites its 
TSW. 

LOGON - SVC 1 1 

LOGON acquires an LUBUFFER and a set of local 
registers. Even though it is not associated with an LU, 
LOGON requires a Data Memory work area. Tn order to 
maintain the re-entrant nature oV the I/O supervisor it 
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must acquire this environment for the LUTABLE. For this 
reason there must be at least one LU environment 
available at the time a LOGON SVC is issued. The Control 
Card Processor issues" a GETENV SVC (SVC 10) before it 
issues a LOGON. If a user finds it necessary to LOGON 
using a user ID other than the one used to open the 
jobfile, he must ensure that a buffer is available. 

LOGON copies the twelve character user ID specified 
in the SVC parameter block, and issues a LOGON message to 
the file manager. If the file manager accepts this ID it 
will return the UIC code. This code will be used for all 
successive opens from this task until a new user ID is 
supplied.- Files already opened under another UIC will 
remain under that UIC. If the LOGON is rejected by the 
file manager the error status will be copied into the SVC 
parameter block. The LU Buffer and local register 
environment are returned, and the user re-created. 
Figure E shows the format for a LOGON message to the file 
manager. 

GETCORE - SVC 12 

GETCORE does not require a local register 
environment or LU Buffer. It does not return status. If 
the pointer to the SVC parameter block contained in the 
user's indexed register one (R1:I) is not a valid address 
the supervisor will issue an ABTERM. Otherwise, the 
address of one greater than the last word of user Data 
Memory will be returned in the SVC parameter block. 
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2.4 Error Handler 

Hardware-detected error conditions result in traps to a 
set of low-core addresses. All such errors in user tasks are 
processed by the User Error Handler, which is a Supervisor 
process running in the corresponding task (User Task Number 
+3). When the hardware detects an error condition the task is 
made dormant. The first act of the supervisor is to issue a 
KILL instruction followed by an ACTivate on the user task. 
This will insure that all processes in the task are 
terminated. Then the supervisor will call an I/O Supervisor 
CLOSEALL to insure that all opened files are closed. The 
Supervisor then builds an abnormal termination (ABTERM) 
message which consists of three words containing: 

a) Trap PSW; 

b) User PSW at time of error; 

c) Instruction generating the trap. 

This message is sent to the Kernel, and is normally printed 
on the System Console by the Batch Monitor. 

When a Cancel Task message is sent from the Host, the 
Kernel creates a process in the user task with all bits on 
except the PS field. It is then treated as any other ABTERM. 

When the Kernel receives a Suspend Task message from the 
Host, it creates a process in the user task at location zero, 
with all UTM bits on. This is a special case in which the 
Supervisor simply vectors the PSW which trapped to the quit 
at instruction zero, and issues a Pause request message with 
no -text to the Kernel. 

The User Error Handler shares the global supervisor 
registers and data memory with the I/O Supervisor. It must 
therefore observe the same semaphoring conventions on those 
resources in order to avoid conflicts. 
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3. SYSTEM SOFTWARE 

3.1 Control Card Processor Overview 

HEP Control Card Processor (CCP) is a system program which 
processes certain records in the user job file. CCP is 
responsible for allocating and opening all disk files for the 
user Partition as a result of submitting a job. After processing 
the records in the Job File, CCP terminates, leaving all files 
open, with the user load file assigned to LU zero. 

If CCP encounters an error in the Job File, such as an 
illegal command or not being able to open a file with the 
requested privileges, all open files will be closed, and the Job 
will be terminated. 

All CCP commands must begin in column one and unless 
otherwise stated, must be followed by at least one blank. 
Commands recognized by CCP are:" 

JOB - Job Specification Record 

ASN - File Allocation and Assignment Record 

DMP - Conditional Dump Record 

RUN - Run Record - Specifies Load File and and End of Job 
Step 

// - End of Job Record - Terminates All Job Steps 

'*' - Comment - Any Record Beginning With an '*' is 
Treated as a Comment 
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3.1.1 Control Card Processor Command Syntax 

The following commands are accepted by CCP. Even though 
other commands may be recognized by the READER, by the time 
CCP receives access to the Job File they should be commented 
out . 

3.1.1.1 Job Record Syntax 

JOEKJobname Followed by Job Environment Requirements> 

This record is copied into Logfile with no further 
processing required by CCP. The first record in a Jobfile 
must be a Job Record. 

3.1.1.2 Assign Command Syntax 

ASN LU,FILENAME[ , Logical Reclen, Accpriv, Owners Accpriv, 

Public Accpriv, I/O Direction, File 
History, File Disposition, Buffer Count] 

[1 - Indicates optional parameters, not 
order dependent. 

Example: ASN 5, CARDFILE , REC : 80 , ER, F, OLD, 
KEEP-.DELETE 

Accpriv - A single letter for each access privilege, may 
be specified in any order. 

Prefix - Indicates Owners Privileges 

Prefix P - Indicates Public Privilges 

No Prefix - Privileges For This Open 

R - Read Access 

W - Write Access 

X - Extend Access 

E - Exclusive Access 

S - Semaphored Access - 

(Implemented in H3FS Only) 

D - Delete/Rename Access 
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If file is being newly created, and P Accprivs become 
the permanent attributes of the file. 

If file already exists, and P Accprivs are ignored. 

DEFAULT - (No Accpriv Specified) 

For this open - R - read access 
For owner if creating file - WXED 

Write, Extend, Exclusive, Delete/Rename 
For public if creating file - No privileges 



I/O Direction - A Single Letter 

F - Forward - Open at beginning of file, do I/O in 

forward direction 

B - Backward - Open at end of file, do I/O in forward 

direction (implemented in HSFS only). 

A - Append - Open at end of file, do I/O in forward 

direction (X - Extend Access must be 
allowed for appending) . 

DEFAULT is F - Forward I/O. 



File History - 

USE - Use old file if present, elr.e create new 
file. 

NEW - Create new file, delete old file if 
present . 

OLD - Use old file, fail if not present. 

CREATE - Create new file, fail if old file present. 

DEFAULT - (Mo history specified at all) is USE. 
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File Disposition - 

DELETE - Delete on any close. 

KEEP - Keep on any close. 

DELETE:KEEP - Delete on normal (user) close - 

Retain on abnormal (system) close. 

KEEPrDELETE - Keep on normal (user) close - 

Delete on abnormal (system) close 

DEFAULT - (No disposition specified) is: 

If old file used, KEEP on any close - 
If newly created file, DELETE on any 
close . 

Logical Reclen - 

REC:n or n 

Where n = Desired logical record length in HEP 
words. 

If file is being created, n becomes the default 
RECLEN for the file and if n = 0, or f is not 
specified, a word file is assumed. 

If file already exists - 

If n = it is treated as a word file for this open. 
If n is not specified the default RECLEN for the 
file is used . 
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Buffer Count - 

Number of buffers allocated in HEP Data Memory for 
this open of this file (implemented in HSFS only). 

BUF:m 

Where m - Number of Buffers Desired. 

DEFAULT is 2 Buffers. 

(NOTE: In standard file system implementations 
Buffer Count defaults to one, even if BUF is 
specified in a Control Card.) 

3.1.1.3 Conditional Dump Command Syntax 

DMP[ALWAYS][ (MEMORY TYPES)] 

ALWAYS - Specifies dump after any termination. 

Default is dump after abnormal 
termination . 

(MEMORY TYPES) - P - Program 

R - Register 
C - Constant 
D - Data 

Memory types to be dumped, enclosed in 
parenthesis . 

Default is (RD) Register and Data 
Memory dump. 

Memory type characters may be in any 
order, and should not be separated by 
any other characters. 

Example: 

No DMP Record - No dump will be taken. 

DMP ALWAYS (P) - After any termination, Program 

Memory is dumped. 

DMP (CRD) - After abterm, Constant, Register 

and Data Memory are dumped. 

DMP - After 'abterm, Register and Data 

Memory are dumped. 
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3.1.1.4 Run Command Syntax 

RUN<LOAD FILENAME>[OPTIONAL RUN PARAMETERS] 

<LOAD FTLENAME> - Name of user task to be run. 

[OPTIONAL RUN PARAMETERS] - Copied as ASCII text, left 

justified into user Data 

Memory, beginning at word 

relative to user Data Memory 
base . 

If optional run parameters are 
included, the first ten words 
of user Data Memory will be 
initialized to zero. Then the 
text string will be copied, 
beginning at byte 0, and 
running to the end of the 
input line. 

Example: 

RUM MYFILE.TSK - Load and run MYRTLE. TSK, no 

run parameters. 

RUN HEPTASK A B C D E F - Copy the string 'A B C D E F' 

into user Data Memory 
beginning at word zero and 
blank filled to the the end of 
the input line. Load and run 
HEPTASK. 

3.1.1.5 End. of Job Record Syntax 
// -or- End of File on Jobfile. 

Causes termination of a HEP job. Any open files are 

closed . 

3.1.1.6 Comment Record 

Any string beginning with an asterisk ('*') in column 

on?. 
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Trie HEP Control Card Processor (CCP) is implemented in such a way 

as to make it very easy fcr a user to add features to it, or if 

desired, write a new one. Tne following describes the Runtime 
Environment expected by tne CCP. 

3.1.2 Runtime Environment 

CCP runs in tne User Partition just prior to the execution 
of a User Task. In the case of a multi-task job, CCP is loaded 
in tne first partition large enough to hold it. 

CCP Run Parameters 

In User Data Memory beginning with word is the 
following information: 

User ID Code - 12 Bytes, ASCII 

Job Number - 2 Bytes, Binary 

Jobfile Record Number - 2 Bytes, Binary 



UID 



JOB 



REC // 



REC //<0 indicates a dump nas been taken. 

The following filenaming conventions apply to CCP 

Jnnnn.HEP = Jobfile Name 

Lnnnn.HEP = Logfile Name 

Dn n n n . H E P * Dumpfile Name 

Pnnnn.HEP * Dump Formatter Print Filename 
llnere 'nnnn 1 = Job Number 

All of tne above filenames csn be 
fabricated using tne Job Number passed to CCP as a 

run p a r a meter . 
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Jcbfile Record Number (word 1, 4th quarter). 
is the number of tne last record of the Jobfile 
read by CCP for the current job. 

IF RtC //rO tnen this is the first step of 
this job. Begin processing from 
the first record of Jobfile. 

IF REC // > then this is not the first step of 
this job. Begin processing from 
REC # + 1 of Jobfile. 

IF REC #<0 i.e. the high bit of this field is 
set, then this is not the first 
step of this job, and furthermore, 
a dump nas been taken of the HEP 
memory . 

CCP must Open the Dumpfile at LU 1 , 
Open the Dump print file at LU2, 
and Open the Dump Formatter Load 
Module (DMFMT.HLL) at LUO. 

Wnen CCP terminates normally, it passed a 
binary stop code via SVC 7 to tne Batch Monitor, 
of the form ; 



7 8 



63 



DC 



RFC // 



WHERE DC r Dump Code - Applies only to this Job Step. 
Dump Code Conditions - Bits, 2, 3 
No Dump 

Dump or. Abterm 

Dump on Normal Term 

Dump Always 1 1 

16 










16 





1 


1 

16 


1 





2 



16 
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Memory Type to be Dumped 
Program Memory 

Register Memory 

Constant Memory 

Data Memory 



- Bits 4,5,6,7 



1 











3 
16 





1 








4 
16 








1 





2 
16 











1 


1 
16 



Memory Dumped will be the inclusive Or of these 
bits , e.g.: 

XMF' - Dump all memory on abterm. 

X'35' - Dump Register and Data Memory on 
any termination. 

X'OO' - No dump. 

REC // = Number of jobfile record last processed. 

If end of file on the jobfile has been 
encountered the number returned is a zero. 
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In processing LU assignment records the CCP must perform the 
following sequence of Supervisor Calls: 

1) LOGON SVC 11 - Log on using the user ID in Data Memory bytes - 

This must be dons once at the beginning of 
execution, before any files, including the Jobfile 
are opened. 

2) INQUIRE SVC 9 - Inquire regarding the status of an LU. If LU Is 

already opened, SVC 9 will return its current 
default record length, and options. If an LU is 
open* an attempt to open it again, whether for the 
same file or not, will result in an error. 

3) GETENV SVC 10 - Get an LU buffer environment. This must be done 

prior to opening a file. SVC 10 is allowed only to 
CCP. Once gotten, an LU buffer will not be 
returned. If files are opened, and subsequently 
closed before another is opened, an extra SVC 10 is 
not required. The number of SVC 10' s issued must be 
greater than or equal to the number of LU ' s open at 
any time. SVC 10 will not return a status, if it 
fails, the next open will be unsuccessful. 

*D 0PENLU SVC - Open a file at the specified logical unit. 

If the program to be run is a FORTRAN program, or an Assembly 
Language program which uses the FORTRAN I/O Formatter, it is necessary 
that the OPEN and any Input or Output be done via calls to the I/O 
Formatter, as it maintains internal buffers for the opened Logical 
Units. Refer to HEPFMT documentation for a complete description of 1/0 
Formatter routines. 
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3.2 HEP Dump Formatter. 

The HEP Dump Formatter is a system program which runs in a 
user partition immediately following the execution of a job for 
which a memory dump is taken. The purpose of the Dump Formatter 
is to translate the binary dump file into a printable and more 
legible format. The Dump Formatter is loaded by the Control Card 
Processor at the instruction of the Batch Monitor, immediately 
after the dump is taken. In the case of a multi-step job, if a 
dump is taken it will be formatted before the next step in the 
job is executed. 

A typical dump will contain the UIC (User ID Code), job 
number, jobfile record number, job name, processor and task 
numbers for each task in the user job, user and supervisor TSW s 
for each task, system table entries, user and supervisor PSW's 
and the contents of the entire partition for each memory type 
specified . 

A user may request that a dump be taken either after an 
Abnormal Termination (A3TERM),. or after any termination of his 
job. He may also specify which memory types are to be dumped. 
This is accomplished by the DMP command in the jobfile. Depending 
on the information in the DMP command, the Batch Monitor 
initiates a dump upon receiving a job complete message from the 
Kernel. This binary dump will be output to a newly created file 
with a name of 'Dnnnn.HEP', where 'nnnn' is the job number. This 
is a record file with a logical record length of 129 words. It 
will contain one header record followed by one task record and 
one PSW record for each task. Then will come the memory dump 
records for the memory types specified, in the following order: 
Data Memory, then Register Memory, Constant Memory and Program 
Memory for the first task, followed by the Register, Constant and 
Program Memory for the second task, and so on. Figure A contains 
a diagram of the dump file record formats. 
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Word 



Word 



Word 




1 
2 
3 

5 

6 
7 
8 
9 
10 
1 1 



65 



123 



UIC U 2 BYTES) 



JOB NUMBERl RECORD NUMBER 



JOB NAME 



UNUSED 




ALL USER 



ALL SUPERVISOR 



3*4 



10 





1 


34 10 




P 


T 


USER TSW 






SUPERVISOR TSW 


TASK'S SYSTEM 
TABLE ENTRIES 


UNUSF.n 






^^^^ 







HEADER 
RECORD 



TASK 
RECORD 
(1 PER 
TASK) 



PSW 

RECORD 

(1 PER 

TASK) 



Word 



127 
128 



P 


3 




MEM 
TYPE 


37 10 


BLOCK START ADORF.^ 






6? DO/DATA FATRS 












UNUSED 



DATA 
RECORDS 



Figure A - DUMPFILE RECORD FORMATS 
Logical Record Length = 129 Words 
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Figure A - DUMPFILE RECORD FORMATS 
Logical Record Length = 129 Words 
The following describes the processing necessary for each record 
type. 

Header Record - Contains UIC, job number, job . file record 

number and job name. 

Task Records - (1 per task) - Contain processor number, task 

number, user TSW, supervisor TSW and system 
table entries. The system table entries give 
the starting address and length of the Data, 
Register, Constant and Program Memory 
partitions, and the maximum number of processes 
allowed for the task. The user TSW contains the 
base and limit addresses for the user's memory 
partitions. Using this information a table of 
supervisor base, user base, user limit and 
supervisor limit is set up for each memory 
type. This table will be referred to in 
processing the Data Records. 

P3W Records - (1 per task) - Contain all of the PSW's in the 

PEM at the time of the dump. The first 6*1 are 
user PSW's; the last 54 are supervisors. The 
Dump Formatter scans through this record 
comparing the PT field with the PT specified in 
the Task Record. Those PSW's which belong to 
the task in question are output to the 
pr intf ile . 

Data Records - Using the information in the first two words, 

the absolute address of each word in the record 
is calculated. This address is compared with 
the base and limit Table entries for the 
appropriate memory type to determine whether it 
is a supervisor or user, and within the 
partition. If the end of the memory partition 
falls within a record buffer, the buffer is 
filled with as many words as necessary beyond 
the end of the partition. 

In a Data Record the word immediately 
proceeding a memory is its register descriptor. 
The following processing is necessary for each 
memory type: (see Figure B) 
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Register 



Empty/full bit and reserved bits are 
checked, and 'E'/'F' and 'R' are 
printed,. The number representing data 
quality is printed, and parity is 
calculated. If the parity bit in the DQ 
is not correct an '*' is printed. 



Data 



Empty/full bit is checked, and 'E'/'F' 
is printed. The data quality number is 
printed and parity is checked. If parity 
is incorrect an '*' is printed. 

Constant : Parity is calculated. If the parity bit 
is incorrect an '*' is printed. 

Program : The Register Descriptor field is ignored 
for Program Memory. 

Finally, the address, memory type, supervisor/user's status, 
register descriptor field and memory contents are printed, four 
words to a line. If the supervisor/user's status or memory type 
is different from the previous word, the current line is 
terminated, and several lines skipped to dilineate the change. If 
more than two lines in a row would be identical except for the 
address, the message •**** THROUGH ****' is printed, and all but 
the first and last lines are left unprinted. 



I 



59 60 61 6? 63 



R 



L- 



Tq 




P = Parity Bit 

E = Empty Bit = 1 - Empty, = - Full 

R = Reserved Bit = 1 - Reserved 

DQ = Bits 61=63 Represent Data Quality 



Register Descriptor Word Format 
Figure B 
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3.4.2 HEP I/O Formatter 

The HEP I/O Formatter is a set of system subroutines 
which is included in the user Load Module. It provides an 
interface between the FORTRAN program and the I/O Supervisor. 
The I/O Formatter is responsible for performing formatted and 
unformatted I/O, opening and closing logical units, 
backspace, rewind and endfile, and issuing STOP and PAUSE 
requests. It is primarily record and logical unit oriented. 
If a user wishes to write an Assembly Language program which 
utilizes the ( I/O Formatter, it must be done in the same 
manner as a FORTRAN program. The following describes the 
interface between the user program (FORTRAN or Assembler) and 
the I/O Formatter. 

OPEN and CLOSE are called using the standard HEP FORTRAN 
calling sequence, with parameters as follows: 



CALL OPEN (LU // , Filename, Logical Record Length, 
Options Word) 

CALL CLOSE (LU // , filename, Logical Record Length, 
Options Word) 



Parameter blocks for all other I/O Formatter routines 
have special formats (See Figure B) . In all cases, as with 
any FORTRAN subroutine, indexed register zero (R0:T.) contains 
a pointer to the user's Data Memory Base, indexed register 
one (R1:I), a pointer to the parameter block, and the low 32 
bits of indexed register two (R2:I) contain the return PC. 
The word immediately following the parameter block must 
contain a -1. This is beeause OPEN and CLOSE may be called 
with a variable number of parameters, and the end of a 
parameter block is designated by a -1. 
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F*,READ/F'7>WRITE 



>p FORMAT 


LU 


M UMBER 


END=RETURM PC 




ERR = 


RETURN PC 





F3IOLST 







LU 


NUMBER 


LENGTH -1 (ARRAY ELEMENTS) 


t I/O ITEM 





F^STOPT 







LU 


NUMBER 








F7>BSPAC/F%RWTND/F%WEOP' 


o 




LU 


NUMBER 








F*STOP/F%PAUSE 


TEXT LENGTH (HEP WORDS)! 







TEXT 

F^BUFTM/F%BUFOU 







LU 


NUMBER 


EMD=RETURN PC 




ERR = 


RETURN PC 


t ARRAY 




LENGTH 


(HEP WORDS) 



Upon CALL 

RO = t User's Data Memory Base 

R1 = ^ Parameter Block 

R2 = Return PSW 



Figure B 
HEP FORTRAN - I/O Formatter Interface 
Parameter Block Formats 

Revision 3/30/81 A ,, < 
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I/O Formatter Entry Points 

(Refer to Figure B for parameter block formats.) 

OPEN/CLOSE 

OPEN acquires an LU Buffer, -and issues an 
SVC 0, to open the file specified, at the LU 
specified. If a record length is not specified (i.e. 
the third parameter negative) the default record 
length for the file is used. If record length is 
zero the file is treated as a word file. Any other 
record length supplied is considered the record 
length for this open. WARNING: Attempts at formatted 
I/O on a word file may have unpredictable side 
effects. The I/O Formatter is record oriented. 

CLOSE frees the LU Buffer, and issues an SVC 1 
to close the file specified. If a filename parameter 
is specified it will attempt to rename the file, and 
if record length or options v/ord parameters are 
included, these will also be copied into the SVC 
parameter block. Close may be called with only an LU 
number parameter if desired. 

A user may open and/or allocate a file by name, 
and close or delete or rename a file using the OPEN 
and CLOSE subroutines in the I/O Formatter. These 
activities are accomplished by means of the Options 
Word parameter. This word is copied directly into 
the SVC parameter block by the subroutine. It is 
divided into several one byte fields which have the 
following meanings: 

A - Requested Access Privileges For This Open 

B - Public Access Privileges 

C - Owners Access Privileges 

D - History 

E - Disposition 

F - I/O Direction 

G - Buffer Count 
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Access Privileges - Fields A, B, and C 

If the file is being created (open) the 
privileges requested in these fields become part of 
the permanent attributes of the file. On a close, if 
the high bit of each field is set, these become the 
new attributes of the file. 

Bit Definitions 

1 Read Access . 

1. Write Access - Update Records. 

1.. Extend Access - Add Records. 



....1... Exclusive Access - No Other Concurrent 
Opens 'Allowed . 



* 



...1.... Semaphored Access - May Consume and 
Fill Records. 

..1 Rename/Delete Access. 

. 1 Undefined. 

1 Change Privileges. 



* Semaphored access is unimplemented in the 
standard file system. 



For field A, current access privileges, the 

default privilege is read access only. 

For field B, public access, the default is 
no public access. 

For field C, owner's access, the default is 

read, write, extend, exclusive and rename 
(00101111 ) access. 
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File History - Field D 

Determine whether to use an old file or create 
a new file. 

Values: 

0-lise old file if present, else create new 
file - this is the default. 

1-Create new file, delete old file if present. 

2-Use old file, fail if not present. 

3-Create new file, fail if old file is present. 



File Disposition - Field E 

Specifies the disposition of the file upon 
close. Entries in this field on open are kept until 
the close. If no entries are specified on close 
those specified with the open will be used, 

O-Keep old file, delete new file - default. 

1-Delete file on close. 

2-Retain file on close. 

*3-Retain file on system close (i.e. ABTERM), 
delete on user close (normal termination). 

*4-Retain on user close, delete on system close. 

**5-Retain and rename file. 

* These have meaning only on open. 
** Valid for close only. 



In the case of a file opened several times the 
last disposition specified (open or close) in 
chronological order determines the file d is posit ion 
which will be used . 
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I/O Direction - Field F 

Controls the initial positioning of the file, 
and the direction for sequential access. This field 
is ignored by close. 

O-Forward - Open file positioned at the 
beginning of the first record, do I/O in 
forward direction - default. 

1 -Backward - Open file positioned at the 
- beginning of the last logical record, do I/O 

in reverse direction - this is unimplemented 

in the standard file system. 

2-Append - Open file positioned at the end of 
the last logical record, do I/O in forward 
direction - (appending to a- file requires 
extend privilege) . 



Buffer Count - Field G 

Number of physical records to be held in I/O 
Cache at any time, this feature is unimplemented in 
the standard file system. All entries in this field 
will be ignored by the I/O supervisor. 



RXREAD/F^WRITE 

READ and WRITE seize the LU Buffer for the LU 
specified, and prepare it for I/O, marking it busy, 
and setting up the ERR= and END = return addresses, 
and the format pointer, if they are specified. 

F'UOLST 

IOLISTITEM performs whatever processing is 

necessary for the I/O Item (Scalar or Array) 

specified. When the buffer is full (in the case of 

WRITE) or empty (in the case of READ) it issues the 
appropriate SVC. 
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F3STOPI 

STOPIO finishes processing of the format 
statement if necessary, and marks the LU Buffer 
available for another I/O. 

F^BUFIN/FfcBUFOU 

BUFFERIN and BUFFEROUT combine the actions of 
READ/WRITE, IOLIST and STOPIO for unformatted I/O to 
(from) a single 10 item (Scalar or Array). They 
acquire an LU Buffer, marking it busy, issue the 

requested, and upon 
3uffer and mark it 



SVC ♦ s required for 


the 


1/ 


completion return 


the 


LU 


available . 







F%STOP/F%PAUSE 

STOP and PAUSE issue the appropriate SVC (7 for 
Stop, 8 for Pause) with a pointer to the text 
supplied in the parameter block. 

F£BSPAC/F%RWIND/F%WEOF 

BACKSPACE, REWIND and ENDFILE each acquire the 
LU Buffer specified, and issue the appropriate SVC 
(4, 5, or 6 respectively). 



A typical call sequence for a formatted Read or Write 
would consist of 1) a call to FftREAD (/F'SWRITE), followed by 
2) one or more calls to FXIOLST, one call for each T/0 list 
item, and terminated with 3) a call to F%ST0PI (see 
Example 1). An unformatted I/O operation could be 
accomplished in the same manner, omitting the format pointer 
in the parameter block for the F%READ/F%WRITE call. A more 
efficient method however is to issue a single call to F7.BUFIN 
or F'/oBUFOU (see Example 2). These result in a single 
Call/Return sequence, instead of a minimum of three which 
would be required if I/O is done as with formatted I/O. 
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Example 1: The FORTRAN Statements 
DIMENSION AC2) , B(10) 

READ (6, 1000, END=2000, ERR=3000) A,B,C 
would generate the following series of subroutine calls: 
1) A call to F%READ with a parameter block of 



* LABEL 1000 


f) 


* LABEL 2000 


* LABEL 3000 









2) A call to F'UOLST for the Array A. 






6 


1 


* A 









A second call to F%I0LST for the Array B. 



o • 


6 


? 


>r B 









A final call to F7>I0LST for the Scalar C. 






6 





^ c 









3) A call to F3ST0PI to finish the READ and mark the LU 
available . 






6 















x ample 2: The FORTRAN Statements 

DIMENSION A(5) 

BUFFERIM C>, END=2000, ERR=3000) A 

would generate a subroutine call to F7.BUFTN with a 
parameter block of: 



n 




LABEL 2000 


LABEL ?000 


A 


a 



